[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Ohler
Subject: bug#11218: with-demoted-errors use of condition-case-unless-debug; ert
Date: Sun, 06 May 2012 11:45:07 -0700

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]