From: Philipp Stephani <p.stephani2@gmail.com>
To: Helmut Eller <eller.helmut@gmail.com>, 24617@debbugs.gnu.org
Subject: 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 [thread overview]
Message-ID: <CAArVCkTAP5i0T7eAnKL5x81vYA+7nkzK4-7V2T_mBBO7pRcKjg@mail.gmail.com> (raw)
In-Reply-To: <m28tu3z5f5.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
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).
[-- Attachment #2: Type: text/html, Size: 3030 bytes --]
next prev parent reply other threads:[~2016-12-28 20:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-04 16:38 bug#24617: 26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace Philipp Stephani
2016-10-04 19:41 ` Clément Pit--Claudel
2016-12-28 19:33 ` Philipp Stephani
2016-10-05 6:16 ` Helmut Eller
2016-12-28 20:08 ` Philipp Stephani [this message]
2016-12-29 9:01 ` Helmut Eller
2016-12-29 14:02 ` Clément Pit--Claudel
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=CAArVCkTAP5i0T7eAnKL5x81vYA+7nkzK4-7V2T_mBBO7pRcKjg@mail.gmail.com \
--to=p.stephani2@gmail.com \
--cc=24617@debbugs.gnu.org \
--cc=eller.helmut@gmail.com \
/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.