From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Attaching context info to an error Date: Fri, 29 Dec 2023 11:54:50 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7291"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 29 17:55:53 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 1rJG9I-0001iC-Rz for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Dec 2023 17:55:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJG8T-0006qp-8Q; Fri, 29 Dec 2023 11:55:01 -0500 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 1rJG8O-0006qR-MX for emacs-devel@gnu.org; Fri, 29 Dec 2023 11:54:56 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rJG8M-00026S-TZ for emacs-devel@gnu.org; Fri, 29 Dec 2023 11:54:56 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 021C1838B7; Fri, 29 Dec 2023 11:54:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703868891; bh=RyBmJxjsQbCBaDtrKhP0OhwgvayvflPo8l1moikS1G0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ex29wollyzO6gCRSXl9enb5hf0VLNL17EDVACiRgL8QW612OSPhkymctjg0k1uBs/ fg0erFTY+gI2FHdY5Xi9eYL1yYXO12kntRfkcziMyvF1DbGBu4MjezgvM3zRN5tQIM mIhYN9i4JfFeEvexDwg1iJ93Fz0C9y3UyaM9yhyYLQLN9dOoMce55/3licpxZEYEqw awN0V+hz//2CA/8smuwmXUkA4g36g4sTw+zd8SQQxFmkcR1aufZUvWaiq5KwcIsw5R prFAEhqDZtsSMc3oWycUJK0UvnI7cOjrJgdK5SLFiMU5M37F1HhiqknQAJleLjWKQv qmdK8VCjVmf2g== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B24EB8345A; Fri, 29 Dec 2023 11:54:51 -0500 (EST) Original-Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9B000120AC9; Fri, 29 Dec 2023 11:54:51 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 29 Dec 2023 03:43:54 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:314330 Archived-At: >> > What object exactly goes into the handler bind handlers? >> The same (even `eq`) as the one passed to the `condition-case` handler. > Would it matter if it weren't? I think we want to preserve the identity of an error as it passes through its various handlers, yes. That makes it possible to use `eq` hash tables and to mutate them. > - Printing? a cl-print-object would be sufficient, I think, > along with a (orthogonal) directive to 'format' for using > cl-prin1 (why doesn't cl-princ exist?) We cannot reliably distinguish an error object from random other cons cells, so things like `cl-print-object` are simply not an option: the caller needs to tell us that this is an error object. We could have a `print-error-object`, OTOH. > - Getting the type for resignalling purposes? Unfortunately, > this returns 'cons' > > (condition-case err (error "bla") (error (type-of err))) > > Can it be made to return error? If it's only for resignaling purposes, why not have `error-resignal` instead which takes the error object itself? > - Can we import a typep (similar to cl-typep) that understands > basic types EIEIO and also error hierarchy? Nope for the reason mentioned above. But we could have a `error-typep`. AFAIK this kind of operation is very rarely used in ELisp (it's only used internally in the C code which looks for the appropriate handler). > - simple-condition-format-control and > simple-condition-format-arguments? I can't think of any ELisp code I've encountered that does something related, so I think it's a YAGNI. BTW, the best way to find what we need is probably to change the `signal_or_quit` code which does the `Fcons (error_symbol, data)` and make it build something else than a cons instead. Then go and fix all the things that break, introducing new `error-FOO` abstractions along the way. > - change manual to explain that resignalling is discouraged now > that handler-bind exists, but if resignalling _is_ done, then > definitely avoid car and cdr and some form of > > (signal (error-symbol err) (error-data err) > > introducing these new functions? We first want to help people make their existing code compatible with other representations of error objects which minimal changes. Changing the code to use `error-resignal` is trivial whereas making it use `handler-bind` can be difficult since the semantics is subtly different and it's not always easy to judge whether the difference matters in this particular case. > - go through the hierarchy and add - > accessors? I don't think we want to do that systematically, but yes (and I'm afraid we'll discover along the way that the representations we use are messy and don't always obey the subtyping suggested by the error hierarchy). It presumably needs to come with a "similar" change on the constructor side, so as long as we keep using (signal ERROR-TYPE ERROR-DATA) where ERROR-DATA is a bare list it's not super pressing. > They shouldn't be terribly hard to find. From some greps I > estimate there less than 700 condition-case that actually use > the variable and the majority seems to be resignalling or > printing. The former will probably be fixed by > handler-bind anyway, and printing is a generic operation > already. I checked about 20 occurances randomly, and they > all fell into this basket. This also tells me that switching > to proper objects isn't that hard. Even better, Stefan