New(?) idea for making backtraces usable: condition-case*

New(?) idea for making backtraces usable: condition-case*

[Gerd Möllmann]

Hi Alan,

not sure if you mean that with the "new? in the title, but Common Lisp 
has something in that department: handler-case, for example:

http://clhs.lisp.se/Body/m_hand_1.htm

New(?) idea for making backtraces usable: condition-case*

[Alan Mackenzie]

Hello, Emacs.

condition-case's are an unfortunate fact of Emacs life - Typically, when
a signal is signalled to indicate a bug in the called code, the condition
case unavoidably discards the most useful part of the backtrace.  This
conundrum gave rise (I think) to bug #50629 "hard to debug an uncaught
error with ert" raised by Mike Kupfer on 2021-09-16.

My idea here is to write a new special form, condition-case*.  This would
behave the same as condition-case unless a signal is signalled.  In that
case the error handler forms would evaluate _before_ the specpdl gets
unwound.  This unwinding would take place on exiting an error handler in
the form.  The unwinding would NOT happen if the error handler is exited
with, say, signal.  This would give nested condition-case*'s the chance
to output a full backtrace.

In the event of generating a backtrace, the entire stack at the point of
failure would get output.

Possibly, a new function unwind-stack might be needed, so that an error
handler can unwind the stack explicitly.  I haven't thought this through,
yet.

The implementation should be relatively straightforward, extending the
existing mechanisms in eval.c.

Once it's working, large numbers of condition-case's could be replaced by
condition-case*, easing large amounts of debugging.

What do people think?

-- 
Alan Mackenzie (Nuremberg, Germany)

Re: New(?) idea for making backtraces usable: condition-case*

[Eli Zaretskii]

> Date: Mon, 17 Jul 2023 13:52:20 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Emacs.
> 
> condition-case's are an unfortunate fact of Emacs life - Typically, when
> a signal is signalled to indicate a bug in the called code, the condition
> case unavoidably discards the most useful part of the backtrace.  This
> conundrum gave rise (I think) to bug #50629 "hard to debug an uncaught
> error with ert" raised by Mike Kupfer on 2021-09-16.
> 
> My idea here is to write a new special form, condition-case*.  This would
> behave the same as condition-case unless a signal is signalled.  In that
> case the error handler forms would evaluate _before_ the specpdl gets
> unwound.  This unwinding would take place on exiting an error handler in
> the form.  The unwinding would NOT happen if the error handler is exited
> with, say, signal.  This would give nested condition-case*'s the chance
> to output a full backtrace.
> 
> In the event of generating a backtrace, the entire stack at the point of
> failure would get output.
> 
> Possibly, a new function unwind-stack might be needed, so that an error
> handler can unwind the stack explicitly.  I haven't thought this through,
> yet.
> 
> The implementation should be relatively straightforward, extending the
> existing mechanisms in eval.c.
> 
> Once it's working, large numbers of condition-case's could be replaced by
> condition-case*, easing large amounts of debugging.
> 
> What do people think?

I don't think I understand what will this give us that we don't
already have with the following three existing features:

  . setting debug-on-signal non-nil
  . using 'debug' among the condition-case's conditions
  . using condition-case-unless-debug

Re: New(?) idea for making backtraces usable: condition-case*

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > My idea here is to write a new special form, condition-case*.  This would
  > > behave the same as condition-case unless a signal is signalled.  In that
  > > case the error handler forms would evaluate _before_ the specpdl gets
  > > unwound.  This unwinding would take place on exiting an error handler in
  > > the form.  The unwinding would NOT happen if the error handler is exited
  > > with, say, signal.  This would give nested condition-case*'s the chance
  > > to output a full backtrace.

I thinmk it is unclean for `condition-case' (or a variant of it) to run
its cleanups in a context other than its own.  We have ways to get
backtraces from where the error was signaled, and if other ways
to do that would be useful we can add them, but I think they should
not resemble `condition-case'.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New(?) idea for making backtraces usable: condition-case*

[Alan Mackenzie]

Hello, Eli.

On Mon, Jul 17, 2023 at 19:12:15 +0300, Eli Zaretskii wrote:
> > Date: Mon, 17 Jul 2023 13:52:20 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Hello, Emacs.

> > condition-case's are an unfortunate fact of Emacs life - Typically, when
> > a signal is signalled to indicate a bug in the called code, the condition
> > case unavoidably discards the most useful part of the backtrace.  This
> > conundrum gave rise (I think) to bug #50629 "hard to debug an uncaught
> > error with ert" raised by Mike Kupfer on 2021-09-16.

> > My idea here is to write a new special form, condition-case*.  This would
> > behave the same as condition-case unless a signal is signalled.  In that
> > case the error handler forms would evaluate _before_ the specpdl gets
> > unwound.  This unwinding would take place on exiting an error handler in
> > the form.  The unwinding would NOT happen if the error handler is exited
> > with, say, signal.  This would give nested condition-case*'s the chance
> > to output a full backtrace.

> > In the event of generating a backtrace, the entire stack at the point of
> > failure would get output.

> > Possibly, a new function unwind-stack might be needed, so that an error
> > handler can unwind the stack explicitly.  I haven't thought this through,
> > yet.

> > The implementation should be relatively straightforward, extending the
> > existing mechanisms in eval.c.

> > Once it's working, large numbers of condition-case's could be replaced by
> > condition-case*, easing large amounts of debugging.

> > What do people think?

> I don't think I understand what will this give us that we don't
> already have with the following three existing features:

>   . setting debug-on-signal non-nil
>   . using 'debug' among the condition-case's conditions
>   . using condition-case-unless-debug

Maybe not very much.

I've tried using debug-on-signal, but it triggers just too often to be
helpful.

I didn't know that one can usefully put `debug' in a condition-case
condition (which is what condition-case-unless-debug does).  So, thanks
for the education!

But we only have 33 uses of condition-case-unless-debug as against 1661
of condition-case.  There're probably a lot of the latter that could
usefully be changed into the former.

Anyhow, I withdraw my proposal for condition-case*.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New(?) idea for making backtraces usable: condition-case*

[Eli Zaretskii]

> Date: Wed, 19 Jul 2023 20:35:06 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> >   . setting debug-on-signal non-nil
> >   . using 'debug' among the condition-case's conditions
> >   . using condition-case-unless-debug
> 
> Maybe not very much.
> 
> I've tried using debug-on-signal, but it triggers just too often to be
> helpful.
> 
> I didn't know that one can usefully put `debug' in a condition-case
> condition (which is what condition-case-unless-debug does).  So, thanks
> for the education!
> 
> But we only have 33 uses of condition-case-unless-debug as against 1661
> of condition-case.  There're probably a lot of the latter that could
> usefully be changed into the former.

Right, but then we have zero uses of condition-case* ;-)

> Anyhow, I withdraw my proposal for condition-case*.

Understood.

Re: New(?) idea for making backtraces usable: condition-case*

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I've tried using debug-on-signal, but it triggers just too often to be
  > helpful.

It would not be terribly hard or ugly to create new ways of speciflng
which signals or errors should call the debugger.  They could implement
whatever additional conditions you like, by specifying a function to call
which should return non-nil to call the debugger.

What would make this simple and clean is that instead of saving
backtrace information to be looked at later, it would call the debugger
instead of copying a selectio of data in internatl formats.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New(?) idea for making backtraces usable: condition-case*

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Thu, 20 Jul 2023 22:42:45 -0400
> 
>   > I've tried using debug-on-signal, but it triggers just too often to be
>   > helpful.
> 
> It would not be terribly hard or ugly to create new ways of speciflng
> which signals or errors should call the debugger.

We already have that for debug-on-error: the value could be a list of
errors, not just nil or t.

Re: New(?) idea for making backtraces usable: condition-case*

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> We already have that for debug-on-error: the value could be a list of
> errors, not just nil or t.

I think that one of the legitimate uses that is still not covered is ERT
backtraces. ERT wants to do some additional processing, not just throw a
backtrace.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New(?) idea for making backtraces usable: condition-case*

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > My idea here is to write a new special form, condition-case*.  This would
  > behave the same as condition-case unless a signal is signalled.  In that
  > case the error handler forms would evaluate _before_ the specpdl gets
  > unwound.  This unwinding would take place on exiting an error handler in
  > the form.  The unwinding would NOT happen if the error handler is exited
  > with, say, signal.  This would give nested condition-case*'s the chance
  > to output a full backtrace.

  > In the event of generating a backtrace, the entire stack at the point of
  > failure would get output.

  > Possibly, a new function unwind-stack might be needed, so that an error
  > handler can unwind the stack explicitly.  I haven't thought this through,
  > yet.

This is a lot of complexity and risk of problems.  I think that stems
from trying to do the work in Lisp and make it super-flexible.

I conclude that that is not the right approach for this.  We need
ways to save some information when an error happens, but we don't
need to make it totally flexible, and doing so could make it
much harder to write, and less convenient to use anyway.

And it should not be limited to the scope of one construct.
If variables control it, any way of binding the variable will
do the job.

A feature to do _enough and no more_, implemented mostly in C, would
be simpler and avoid raising problematical corner cases.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)