GNU bug report logs - #24617
26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace

Previous Next

Full log

Message #17 received at 24617 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Helmut Eller <eller.helmut <at> gmail.com>, 24617 <at> debbugs.gnu.org
Subject: Re: bug#24617: 26.0.50; Handlers in `condition-case' should have
 programmatic access to the backtrace
Date: Wed, 28 Dec 2016 20:08:12 +0000

[Message part 1 (text/plain, inline)]

Helmut Eller <eller.helmut <at> gmail.com> schrieb am Mi., 5. Okt. 2016 um
08:18 Uhr:

> On Tue, Oct 04 2016, Philipp Stephani wrote:
>
> > Currently a handler in a `condition-case' form doesn't have access to
> > the backtrace that was active when the signal was raised.  This makes
> > many useful things impossible, such as re-raising signals or returning
> > the backtrace to emacsclient.  I suggest either adding true exception
> > objects (storing the error symbol, data, and backtrace), or at least
> > providing a dynamic variable with the current backtrace.
>
> First, you can copy the backtrace in a signal-hook-function and store it
> in global variable.
>

Yes, that sounds like a good workaround, with the downside that other
libraries might override signal-hook-function and disable that
functionality.
Do you know why ERT uses a custom debugger instead of signal-hook-function?


>
> Second, unconditionally copying the backtrace would be expensive


Are you sure about that? In languages that are typically far more
performance-sensitive (e.g. Java), the backtrace is also copied
unconditionally.


> and
> would still not allow access to local variables in stack frames or the
> value of dynamic variables at the point where the error was signalled
> Just because Java or Python do that doesn't make it a great idea.
>

True, but having the function names and argument values is better than
nothing when debugging the cause of a signal.


>
> Third, the solution to this problem in Common Lisp is the HANDLER-CASE
> macro which is similar to condition-case but the error handlers are
> executed without unwinding the stack.  That doesn't require any copying
> and gives full access to the stack.


That sounds like an interesting approach that could be made to solve some
common use cases (e.g. test runners or rethrowing signals).

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.