bug#9463: 24.0.50; Errors should not be continuable

[Helmut Eller <eller.helmut@gmail.com>]

* Stefan Monnier [2011-09-09 02:23] writes:

>>>> emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))'
>>>> enters the debugger.  Pressing c somehow manages to continue.  That make
>>>> no sense to me.  The debugger should instead not continue and say
>>>> that errors are not continuable.
>>> 
>>> "c" in errors now "continues" in the sense of "do what would have
>>> happened if the debugger had not been called".  I.e. it will actually
>>> signal the error which can then be caught by condition-cases further up
>>> the stack, .... I.e. it's very similar to what happens with "q", but is
>>> often cleaner.
>> I think the "do what would have happened if the debugger had not been
>> called" thing should be a different command, like resignal or abort.
>
> Why?

1. Why not? 

> When the debugger is called in a non-error case, the "c" does just
> that "do whatever would have happened if the debug call had no taken place".

2. it's an incompatible change

3. it's frustrating when people introduce DWIM-ish features when my
expectations are completely different

>
>> c should only continue from truly continuable situations, like
>> breakpoints.
>
> Again: why?

4. it's easy to accidentally press c when using d and c multiple times

5. I have already lost valuable information (and time) because of this
too eager stack unwinding.

6. there is nothing wrong with the traditional distinction between
continuable and non-continuable situations


>
>
>         Stefan
>
> PS: The change you seem to dislike is a bug-fix in my opinion, and it has
> fixed a few real problems

It introduced a new bug: r can now be used in every situation.

> (e.g. when you enter the debugger from within
> a minibuffer, you can now continue your minibuffer operation, whereas
> earlier you could only abort back to the top-level).

You could do that just as well with a separate resignal command.

Helmut