bug#11218: with-demoted-errors use of condition-case-unless-debug; ert

[Christian Ohler <ohler@gnu.org>]

Stefan Monnier, 2012-04-20:

>>> I don't see the point of showing that info when running the tests.
>>> If the user wants that info, he should be able to easily say "run this
>>> test with debug-on-error" so he doesn't only get a backtrace but also
>>> gets put in the debugger where he can inspect the state.
>
>> ERT's keyboard shortcut for that is "d".  But it's not a good solution if:
>
>> * the test is nondeterministic (maybe due to subprocess interaction),
>> * the test takes a long time to run,
>> * you have multiple failing tests and want to quickly compare if they are
>> crashing in the same place,
>> * ERT is running in batch mode (e.g. make check).
>
>> It's better to collect as much data as reasonably possible when the error
>> first occurs.
>
> None of these arguments are really specific to ERT.  It just seems like
> you like to run with debug-on-error, which is fine (I do too).

ERT's default behavior is very different from using Emacs with 
debug-on-error enabled, so in terms of what the user sees, I don't think 
this analogy works very well.


> But don't impose it on all ERT users.

This is not a matter of user preference.  Collecting additional 
information about why the test failed is useful to virtually everyone 
who bothers running the test; there should be no reason not to.  (Even 
if the user doesn't care about the details, it will at least allow them 
to file a better bug report.)  The problem is that the implementation 
doesn't interact well with `with-demoted-errors'.  But that problem is 
not user- or situation-dependent, so it shouldn't be a setting.


>>> No: you'll be put in the debugger for the error "a" but if you hit `c'
>>> it will continue and re-enter the debugger for error "b".
>> My Emacs is a few months old, but that doesn't work for me.  Has it
>> changed recently?
> [...]
>> If `debug-on-error' is t, `with-demoted-errors' becomes essentially
>> equivalent to `progn', and (error "b") can ever be reached in
>
> You're right, sorry: brain malfunction.
> But that just means you first have to fix the bug that signals "a" before
> getting to the bug that signals "b".

If it were that simple, this would be the solution to the OP's problem 
as well: Just fix the errors that are being demoted.

It's a bad solution, though; the user shouldn't have to do this. 
Enabling the debugger should not change the behavior of the code being 
debugged.  It's a design flaw in `with-demoted-errors' that its behavior 
depends on the same variable that controls the debugger.  The proper 
solution is to decouple the behaviors, perhaps by splitting the 
variable, perhaps by some other means.

Christian.