From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Attaching context info to an error Date: Fri, 29 Dec 2023 17:29:26 +0000 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="14515"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 29 18:30:31 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 1rJGgp-0003ZB-9q for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Dec 2023 18:30:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJGg5-0000ne-BH; Fri, 29 Dec 2023 12:29:46 -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 1rJGg3-0000nR-8O for emacs-devel@gnu.org; Fri, 29 Dec 2023 12:29:43 -0500 Original-Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rJGg1-0008AB-Jb for emacs-devel@gnu.org; Fri, 29 Dec 2023 12:29:43 -0500 Original-Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2ccebd0377fso11266601fa.3 for ; Fri, 29 Dec 2023 09:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703870979; x=1704475779; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=b41fE0b/hzN9GCbGpTb4MYhYn5KsHkwxG27+F9kFm+Q=; b=AvTExvMzaQxp0WFleoKS4CcfAXbZ513kfNfLs0oN3p+SbEh448jLfJ5DprWNPTyOq/ 0ijKCa9IGRfw8v+uBPkBsPRO6tG6aJUv4lkHjdn+zWBTPTePbgWe4DwA/fgu66AjePKI HAXp1Rf1zdbRVBEsB6a5QB7uF5CnQIOgWEtOD8D7J67dfjBBKsSt7T87GWbmu74xOi8k B/+L0TiXbcWOJWJSkymJQvTrqrZKXWOu3jnQL+lSU6J1gY2t3v3qN741jAnUpLAl5kDS V1bPZAhgBN0AosrXLa3qzC8t8VDnPwmreap236jlIpM3L1PZ8VPyR+Z33/vrFFYp2Tlf IYcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703870979; x=1704475779; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=b41fE0b/hzN9GCbGpTb4MYhYn5KsHkwxG27+F9kFm+Q=; b=Bqq3Q2wPIC/gNzQKhTTN8H2mLFB+9vzBmrmAktqX4Kgrgo7fQ5/w5bV/nwVWUtNLxy 0nDMaGQFh20MmiVhNr1BSGlhR7i2z0lufRsKjKNGHzzdKWDZsIwZbA0SwCTYdWytheyM t3qPS8Epwj/t65q0u/zTdBKjkON2gH8YE8rT2LziDEnbzjG6LC3t1/QT10GXd3SwEDXq c5If0a3tSaGafvW3dg6l1rGtF56hPR5N1okaYW7PMcFZVGGud4d2dGbr4qBdM3QOGGwt dYkBK1xFx+mlLEM3j94sxjETjM0wGZ/3SupNfIg4X052UrxwsdB6Vi7wkxYY5T62y2l7 udbw== X-Gm-Message-State: AOJu0YwWzXQBEmS254PxsC77x9F2assmiSUSIp2MvNX2ZpPnzs1/05Pe 5alGlGZGW8Mn3crL/t7FtWJXuWKSQv2zlXZbk+Rw3q5M X-Google-Smtp-Source: AGHT+IFZVPz6xt6vJqnz12v6bPL/Tx+eZCTIqJW8EbVyeqmclttfQE+vfWQbf5QwVBy+cKGVQAbGt4dfwP5M/55fJkU= X-Received: by 2002:a2e:980d:0:b0:2c9:fa55:a90e with SMTP id a13-20020a2e980d000000b002c9fa55a90emr2707034ljj.125.1703870979236; Fri, 29 Dec 2023 09:29:39 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x233.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:314333 Archived-At: On Fri, Dec 29, 2023 at 4:54=E2=80=AFPM Stefan Monnier wrote: > > >> > 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. First, I think that's a bad idea for the reasons I explained at length. You should "remember" errors via restarts. 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? So unless there's a specific use for it today, I recommend specifically _not_ maintaining 'eq'ness. This prevents people from making the job to transition to a non-cons representation of errors easier. > > - 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. Indeed this representation is really bothersome. > > - 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? This has to exist indeed. Should be called "condition-resignal" though (and the byte-compiler should warn you should use a handler-bind instead). > > - 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). Let's hope so. Skipping that then. > > - 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. Hard to add with that random data bag'o'things anyway. > 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. True! Let's just preload EIEIO and call make-instance. Ahaha > 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. Makes sense, though 100% of the cases I've seen for resignalling are equivalent functionally to a handler-bind. > > - 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. I've also seen 0 examples so far where the DATA is searched inside for actual properties. Jo=C3=A3o