From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: New(?) idea for making backtraces usable: condition-case* Date: Tue, 18 Jul 2023 22:19:46 -0400 Message-ID: References: Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27647"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 19 04:20:29 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 1qLwnl-0006zL-A1 for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Jul 2023 04:20:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qLwn6-0000ch-5R; Tue, 18 Jul 2023 22:19:48 -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 1qLwn4-0000Yx-MR for emacs-devel@gnu.org; Tue, 18 Jul 2023 22:19:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLwn4-0002CT-EL; Tue, 18 Jul 2023 22:19:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=jqsMOX8GJbbT2X4gf/7KIqGQ+78bYyZzFp4Oax4Xv3w=; b=SVKAQ3Qo8bHb VJbJaPz6k4zrXkXmsNel7+6Dz/vni6FQyU9RgFGIQCgER7A9wwr0IIb3uRJrCy/A9M0UtoB49g5cR lhEMZkshxNWAloTJ9nUUYIy3xfTK8TU3QtHK0p0xOPNj0+guTm2C1OzVeEzeI+zW4M6XhG09xhUud No0kQZUPpbWP+gmQf5OmUIFneEmIiaHY8aeQPjziCB+cnUDfpSA32KcSwyak6oAiVXf72UhzpndNp 0OBIDAzcYYvqUL4KS4GRuXgD/NaYYSNTAD5eLlO+rMBnyVcPnnYQDwujy80jXPzQcbxrEizTHceVf fmoWFt+3aNGk/rJ1aXA1nA==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qLwn4-0003l1-6i; Tue, 18 Jul 2023 22:19:46 -0400 In-Reply-To: (message from Alan Mackenzie on Mon, 17 Jul 2023 13:52:20 +0000) 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:307962 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > 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. This is a lot of complexity and risk of problems. I think that stems from trying to do the work in Lisp and make it super-flexible. I conclude that that is not the right approach for this. We need ways to save some information when an error happens, but we don't need to make it totally flexible, and doing so could make it much harder to write, and less convenient to use anyway. And it should not be limited to the scope of one construct. If variables control it, any way of binding the variable will do the job. A feature to do _enough and no more_, implemented mostly in C, would be simpler and avoid raising problematical corner cases. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)