bug#9463: 24.0.50; Errors should not be continuable

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> 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?

The question is "why" and not "why not": the current behavior is the
logical result of writing simple and the clean code.  Doing something
special when the error is "uncontinuable" requires extra code, so it
needs to be justified by a good reason.

>> 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

It's a user-visible change, yes (it doesn't break any code, AFAIK, so
it's not what we usually consider as "incompatible").

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

There's nothing DWIMish at all about it.

>>> 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

Could you describe a scenario where this would be a problem?

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

I guess the previous scenario would be the same as this one, but if not,
could you describe the scenario where you lost info because of this?

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

The Elisp debugger does not *catch* signals: it just gets invoked at
various points of the execution so you can examine the state.

>> 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.

It does extend an old bug to more situations, but it's hardly
a new bug.  The documentation of debugger-return-value already states
very clearly that it's not always useful to use it.

>> (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.

From an implementation point of view, at least, calling it "resignal"
would be incorrect.

All in all, I think what you're asking is for the debugger to be
informed of the situation in which it is invoked (e.g. because of
a signal, or because of an explicit call, when entering a function, when
exiting a function, ...) so that commands like `r' can tell whether
they'll be useful and so that we can provide a new command "continue
only if this was not a signal" that would behave somewhat like the old
"continue" (tho more cleanly since it would burp right away instead of
doing the previous dance of first continuing, then having the C-level
code figure out that you're trying to continue after a signal and hence
re-enter the debugger with a new error).


        Stefan