From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs 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 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11424262dddbff0544bd8716 X-Trace: blaine.gmane.org 1482955771 26297 195.159.176.226 (28 Dec 2016 20:09:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Dec 2016 20:09:31 +0000 (UTC) To: Helmut Eller , 24617@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 28 21:09:24 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMKXB-0004AY-Dv for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Dec 2016 21:09:13 +0100 Original-Received: from localhost ([::1]:60783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMKXB-0004qc-7M for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Dec 2016 15:09:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMKX5-0004qU-6Y for bug-gnu-emacs@gnu.org; Wed, 28 Dec 2016 15:09:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMKX0-0008Mn-7S for bug-gnu-emacs@gnu.org; Wed, 28 Dec 2016 15:09:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42904) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cMKX0-0008Mj-3U for bug-gnu-emacs@gnu.org; Wed, 28 Dec 2016 15:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cMKWz-0002PR-Sf for bug-gnu-emacs@gnu.org; Wed, 28 Dec 2016 15:09:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Dec 2016 20:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24617-submit@debbugs.gnu.org id=B24617.14829557119217 (code B ref 24617); Wed, 28 Dec 2016 20:09:01 +0000 Original-Received: (at 24617) by debbugs.gnu.org; 28 Dec 2016 20:08:31 +0000 Original-Received: from localhost ([127.0.0.1]:58303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMKWU-0002Ob-LR for submit@debbugs.gnu.org; Wed, 28 Dec 2016 15:08:30 -0500 Original-Received: from mail-wm0-f48.google.com ([74.125.82.48]:34546) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMKWS-0002ON-5D for 24617@debbugs.gnu.org; Wed, 28 Dec 2016 15:08:28 -0500 Original-Received: by mail-wm0-f48.google.com with SMTP id u144so77089957wmu.1 for <24617@debbugs.gnu.org>; Wed, 28 Dec 2016 12:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=VHm06wrv/7t5OhiElbtRF2oQXvA5koVhZusgY2kDjyM=; b=DSmccg67EX3gI/3OCcSuHyvyGIW+U7aiSCQHqkH4FJ5NZTkerbwukfFN3JYqytin2M hpGdVFWbS2dluSOrhi+0iq1/KGqHmQsxDXPysM/u8lX7ZoIbNZrNZXS8wFA7mgA2eaZq UJRsVf1E5Abi1PcVcqjcx5MZahCQPtQE7ii6gR8DIFLsBeLJQ6GP8iULnuIqaJUqF4Z6 nRsPOAtqlB6NVwZLNKSGEvgWXe5VZ6Cbx5+r44oQVN3VANfcBO0ntrqec0u66YsoZWCW 0v+tvC0BdCswxyWMoAbE6VCaVfY9GBq9koeK3QlBNbF6EPZHSrfyFc+h7b657738cm8j 96TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VHm06wrv/7t5OhiElbtRF2oQXvA5koVhZusgY2kDjyM=; b=WbPQwvVZMksNW1LWkeFeNvBhLuXJ7SsqrhdIfGqLzlnqbTI8ZkBm+BrHIy89KEqhBL Zkz/BFpPKMvgqE2jxvSqfFPs5eUDnWx1KknjeVulC2K1sJo8bZxlJyoZNq/pascMnaVc NGq7aA6g6eNbWafV/1BcOJk9k3eRmEc6Z+oqo90UcBIhS2261mcYO8V1/DWGL+Wfa9Wi 8+dTjfylU+NDJnxyI1tHUbH90YVOfKJJSWvZIbnekEuoKBPFjQKmp6bcCG5tz/oL1TIH KrmwDKspwFsTa5TV0foxN5BueHjM5Y6q7/zl23mvrjTJysRb61vSxLJFha860kc57CmD 4V1g== X-Gm-Message-State: AIkVDXI7tzDOnxWF+3dchrP2Hlqch0cpGvqke76nSJRidNlBzwUf9ademh1QJNILxNI0p1fkY9jhkqrldc+8JQ== X-Received: by 10.28.129.81 with SMTP id c78mr35696785wmd.94.1482955702522; Wed, 28 Dec 2016 12:08:22 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127529 Archived-At: --001a11424262dddbff0544bd8716 Content-Type: text/plain; charset=UTF-8 Helmut Eller 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). --001a11424262dddbff0544bd8716 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Helmut= Eller <eller.helmut@gmail.com= > schrieb am Mi., 5. Okt. 2016 um 08:18=C2=A0Uhr:
On Tue, Oct 04 2016, Philipp Stephani wrote:

> Currently a handler in a `condition-case' form doesn't have ac= cess to
> the backtrace that was active when the signal was raised.=C2=A0 This m= akes
> many useful things impossible, such as re-raising signals or returning=
> the backtrace to emacsclient.=C2=A0 I suggest either adding true excep= tion
> 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 libr= aries might override signal-hook-function and disable that functionality.
Do you know why ERT uses a custom debugger instead of signal-hook-= function?
=C2=A0

Second, unconditionally copying the backtrace would be expensive

Are you sure about that? In languages that are typic= ally far more performance-sensitive (e.g. Java), the backtrace is also copi= ed unconditionally.
=C2=A0
an= d
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 fun= ction names and argument values is better than nothing when debugging the c= ause of a signal.
=C2=A0

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.=C2=A0 That doesn't require any co= pying
and gives full access to the stack.

That s= ounds like an interesting approach that could be made to solve some common = use cases (e.g. test runners or rethrowing signals).
--001a11424262dddbff0544bd8716--