bug#9463: 24.0.50; Errors should not be continuable

[Helmut Eller]

* Stefan Monnier [2011-09-09 14:07] writes:

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

That's in the eye beholder.  c shouldn't "do what would have happened if
the debugger had not been called" unless I say so.

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

Let's assume we are hunting down some annoying bug.  The debugger just
popped up and we execute the sequence: d c d c c c c.  The last 4 c are
needed for a loop that has a call to debug.  Now we are at a moderately
interesting place, lets continue: d c.  The last c hits an error but we
are in a hurry and don't see it.  Pressing c again suddenly brings us
back to top-level.  Duh!  The stack is gone.

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

I load some data from the network into a temporary buffer for parsing.
The parser has a bug and invokes the debugger.  Pressing c unwinds the
stack and kills the temporary buffer.  The input from the network is
lost.

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

Interesting way to put it.

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

Are we playing with definitions?

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

Specifically, I'm saying that c should not unwind the stack after
errors.

Helmut