From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: New(?) idea for making backtraces usable: condition-case* Date: Wed, 19 Jul 2023 20:35:06 +0000 Message-ID: References: <83ttu27c0w.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12743"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 19 22:36:19 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qMDuE-00033D-It for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Jul 2023 22:36:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qMDtH-00057J-Ai; Wed, 19 Jul 2023 16:35:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMDtD-000575-TX for emacs-devel@gnu.org; Wed, 19 Jul 2023 16:35:16 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMDtA-0001S9-AA for emacs-devel@gnu.org; Wed, 19 Jul 2023 16:35:15 -0400 Original-Received: (qmail 10968 invoked by uid 3782); 19 Jul 2023 22:35:07 +0200 Original-Received: from acm.muc.de (p4fe159a7.dip0.t-ipconnect.de [79.225.89.167]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 19 Jul 2023 22:35:06 +0200 Original-Received: (qmail 11174 invoked by uid 1000); 19 Jul 2023 20:35:06 -0000 Content-Disposition: inline In-Reply-To: <83ttu27c0w.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307976 Archived-At: 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 > > 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).