Helmut Eller <eller.helmut@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).