From: Helmut Eller <eller.helmut@gmail.com>
To: 9463@debbugs.gnu.org
Subject: bug#9463: 24.0.50; Errors should not be continuable
Date: Fri, 09 Sep 2011 18:37:56 +0200 [thread overview]
Message-ID: <m2litxbriz.fsf@gmail.com> (raw)
In-Reply-To: <m2sjo71bvo.fsf@gmail.com>
* 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
next prev parent reply other threads:[~2011-09-09 16:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-08 12:01 bug#9463: 24.0.50; Errors should not be continuable Helmut Eller
2011-09-08 13:31 ` Stefan Monnier
2011-09-08 18:13 ` Helmut Eller
2011-09-09 2:23 ` Stefan Monnier
2011-09-09 6:53 ` Helmut Eller
2011-09-09 14:07 ` Stefan Monnier
2011-09-09 16:37 ` Helmut Eller [this message]
2011-09-09 21:44 ` Stefan Monnier
2011-09-10 18:27 ` Helmut Eller
2011-09-19 21:17 ` Stefan Monnier
2011-09-20 6:49 ` Helmut Eller
2011-09-20 21:53 ` Stefan Monnier
2011-09-21 8:05 ` Helmut Eller
2011-09-21 19:09 ` Stefan Monnier
2011-09-21 19:53 ` Helmut Eller
2012-02-22 2:20 ` Glenn Morris
2011-09-09 7:10 ` Eli Zaretskii
2011-09-09 7:36 ` Helmut Eller
2011-09-09 7:59 ` Eli Zaretskii
2011-09-09 8:22 ` Helmut Eller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2litxbriz.fsf@gmail.com \
--to=eller.helmut@gmail.com \
--cc=9463@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.