bug#9463: 24.0.50; Errors should not be continuable

[Helmut Eller]

* Stefan Monnier [2011-09-20 21:53] writes:

>>>> Incidentally, C-M-c does pretty much the same as what c does currently.
>>> It does something similar but not identical and hence re-introduces some
>>> of the problems that the change you don't like aimed to solve.
>> And what exactly is the difference between C-M-c and c?
>
> C-M-c does a (throw 'exit), so in the case where we've caught a signal,
> it prevents the condition-case catchers from doing their job.

As matter of fact, c calls exit-recursive-edit (= C-M-c).  
So (throw 'exit) can't be the difference.

Also the debugger is usually not invoked if there is a matching
condition handler, e.g.

  (let ((debug-on-error t)) (condition-case c (error "e") (error c)))

doesn't invoke the debugger.  Let's call this situation 0.

We can have a matching condition handler (only) in these situations:

1. debug-on-error=t and the handler is flagged with debug, e.g.:
   (let ((debug-on-error t)) (condition-case c (error "e") ((debug error) c)))
2. debug-on-signal=t
3. debug-on-quit=t

In 1, 2, and 3 it might be a good thing to continue to unwind the stack.

But the situation I'm interested is like this:

  (let ((debug-on-error t)) (error "foo"))

It is different from 0 and 1 and never has a matching condition handler.

>>> It's important to have a "c" that can "keep going (as much as possible)
>>> as if nothing happened".
>> And why was this not important in previous releases?
>
> That's not a very constructive line of argument, I'm afraid.

c now destroys information (backtrace, temporary buffers) in more
situations than in previous releases.  I hope that we agree on this.

You claim that this is "important".  You neither explain why it is
important nor why not destroying information was a problem previously.

Helmut