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 23:29:02 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11178"; 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 Sat Dec 30 05:29:50 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 1rJQyr-0002kk-Px for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Dec 2023 05:29:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJQyK-0003OW-8G; Fri, 29 Dec 2023 23:29:16 -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 1rJQyI-0003OO-Up for emacs-devel@gnu.org; Fri, 29 Dec 2023 23:29:14 -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 1rJQyH-0005AI-2e for emacs-devel@gnu.org; Fri, 29 Dec 2023 23:29:14 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E3985442A9F; Fri, 29 Dec 2023 23:29:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703910549; bh=5lmjnj4K8OM8LmReoZU23dX5u/w2DdX0jy6Nz637gDA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Dv2GL3Q1jhovcISiaMZTYa4Z5SrAkg1F8mjDnXA3gFsFbs0CvegRK65DLkig47/lh mbZ2UlNBRQ6ULxXZJW2Q8XhTPiJZbQedD5J5dOAtKbQUk0g0FPEPdrco5M/EtqiapT OF+gn3Z6MHtmaDICUB5dNbF09pYrJIyjGBEMngWShv6ZGc2M0SwvzVTkiw+il7f0JV u1QmbtCvi6eWy5c+xvmxgsbTrSzw0Ib5q8dMbQN/4ixNwvIirtOu+MNGV5rFWtBOAn tH0Jj/l5InwMfE4ljaS/ODRC0kz5GrLRiLMreUPFg4S6k599xhpxblFwYEkxqBxUoy t5LVRc9vBcZSw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 227DE442A6A; Fri, 29 Dec 2023 23:29:09 -0500 (EST) Original-Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F337C121187; Fri, 29 Dec 2023 23:29:08 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 29 Dec 2023 17:29:26 +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:314352 Archived-At: > Most importantly, and idea quality apart, who can be doing that > today, before h-b? No-one or practically no-one, since it's useless > because currently the only place user code has access to > the signal also unwinds the stack, and resignalling will make a new > cons. Right? Indeed, until now the identity of an error object can't be "noticed". The only place other than the `condition-case` where an error can appear is in `signal-hook-function` and this doesn't receive the error object (it receives it in two pieces instead =F0=9F=99=81). > So unless there's a specific use for it today, Just because we can't think of a use case today doesn't mean there can't be a good use case. And yes, I do have some use cases. Those use cases may be able to use other approaches as well, but the various options all have pros and cons. > I recommend specifically _not_ maintaining 'eq'ness. > This prevents people from making the job to transition to a non-cons > representation of errors easier. You lost me here. >> 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. > Indeed this representation is really bothersome. Actually, it's not. We've lived with it quite happily for about 40 years now. In practice, we really don't do much with error objects other than re-signal them or pass them to `error-message-string`. >> If it's only for resignaling purposes, why not have >> `error-resignal` instead which takes the error object itself? > This has to exist indeed. Should be called "condition-resignal" > though Emacs's naming convention in this area is a bit murky, but I think it's leaning towards `error` (e.g. the `error-message-string` function, the `define-error` macro, the `error-conditions` and `error-message` properties). This said, as long as the new functions are nicely placed together in their own namespace prefix, I'll be happy, so if you prefer `condition-`, I can go along with that. > (and the byte-compiler should warn you should use a > handler-bind instead). As I mentioned elsewhere, running code inside a `handler-bind` means running in some arbitrary dynamic context, which can have surprising effects because in ELisp dynvars influence the execution of a *lot* of primitives (even `eq` is not immune). So I don't think I can honestly claim that re-signaling an error is almost always wrong. Maybe with more practice, I'll reach this conclusion, but I'm definitely not there yet. So, warning about resignaling seems premature. >> 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. > I've also seen 0 examples so far where the DATA is searched inside > for actual properties. That's my impression as well. The fact that the "data" part has no clearly defined shape (other than being a list) means that it's used a bit "without purpose": I think that in most cases, programmers put data in there only under the expectation that it'll be useful when displayed in an error message or a backtrace. Stefan