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: Sat, 30 Dec 2023 16:45:00 +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="16499"; 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 Sat Dec 30 17:46:28 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 1rJcTk-00042v-N3 for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Dec 2023 17:46:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJcSh-0008It-3F; Sat, 30 Dec 2023 11:45:23 -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 1rJcSe-0008IS-Ie for emacs-devel@gnu.org; Sat, 30 Dec 2023 11:45:20 -0500 Original-Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rJcSa-0001Zd-HY for emacs-devel@gnu.org; Sat, 30 Dec 2023 11:45:19 -0500 Original-Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2cce6bb9b48so23454541fa.1 for ; Sat, 30 Dec 2023 08:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703954713; x=1704559513; 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=Yxes2rIBuuAEhfgRuAvQ6nbFk+XQ6M75J5vlXGX3m4s=; b=Pk0yu+XeN6pFXz7/hmq+ywY+zEvrxFWliYqvyHkrm4YNGdBK3IsvC1O0xfWcpbEwon 1ZZqTQVG0XV+5tboMbHYz3cMQ25RGxq61jnHR6Txnp55+dGV3Nfab0gKu48wk3FQnF9A goIWUuQMzBG7KbBQUTXxMaHSlHoDVkSZ8xI732QZIJzPAMQEQZnVhHedN4/ojU8/b4zM NAXadPibDDGvXWsqkda3F59sKUhhTUqQLLuYomEiplAqVlez7GA3IPfKBZ+HX+fgThdc 5CZaLXjU//LSNLnQCkywpRsuFYwELJOpENb2JCLb9ZaDPqFR3vMM9gfykfPZFFyEF4Vs jSjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703954713; x=1704559513; 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=Yxes2rIBuuAEhfgRuAvQ6nbFk+XQ6M75J5vlXGX3m4s=; b=jjXbXHV5ZE03pxuhAoHymrpfgp1jp0gSGVz5O1+V3cNvyqKGk7P6VqqqSEFX/uZtD/ jiYx6KhjrPuGQ2HRpNGYgaG6xAhF3WIBC558ZTmS87gD+qi9eugWTFHZEIEvWJt2Z6wg UloiBXeIZ4ehwUuUIHBTi9iVZMLz0aKUErRmyeCw+eNJ0ZLNG/xmC32vT6ZThfkeU37P mdjXY9kcOe6kB7RK7NjM5a0cHX7Q8r9HgDoNj4rIBDXmaIkCCH3THotdWi1f98POoThd T176HjOvosc14yoB45fIjy0PxQaRSkWxpeGPKsMA++fpFZ50It/6TXFNU7cqQid0/fzE A3Pg== X-Gm-Message-State: AOJu0Yzlzgwj/KkoMTmoXXEeXBZ5LgeodSpCp0GTsAZg46F2XgLQ4+v5 YEyNWeJkU9Q/AQk3LioLnB1iNMRdl/j/pAgcuRuk6w6Ievw= X-Google-Smtp-Source: AGHT+IGuR3EJQffWrg2bL/hl8HV2lBuhA2JXaWJUtrh+1RWmZu7khnZfMtQv2v7bAiXutj4vjrPUPqAVYyADAwMdfcU= X-Received: by 2002:a2e:b904:0:b0:2cc:7578:3ce6 with SMTP id b4-20020a2eb904000000b002cc75783ce6mr2731033ljb.10.1703954712481; Sat, 30 Dec 2023 08:45:12 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::22c; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x22c.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:314366 Archived-At: On Sat, Dec 30, 2023 at 4:29=E2=80=AFAM Stefan Monnier wrote: > > > 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). Indeed, but that's a good thing IMO. It tells us something we don't _have_ to do, which is always good from a language design evolution point of view. > 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. You're right, so I can go along with `error-` just fine. We can make a zillion aliases later :-) (or not). > > (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. Resignalling a different error is fine, it's sometimes needed. Can be just a different error message. Resignalling the very same error, without changes, is always a fairly bad code smell (in handler-bind-capable languages, in C++ and current Elisp you have no other option). > 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. I'm the exception. :-D I stashed some info in the jsonrpc-error data in hopes they would become useful for things other than printing when handler-bind arrives. And then there's this (condition-case err (electric-pair--with-syntax string-or-comment (scan-sexps (point) (if (> direction 0) (point-max) (- (point-max)))) (funcall at-top-level-or-equivalent-fn)) (scan-error (cond ((or ;; some error happened and it is not of the "ended ;; prematurely" kind... (not (string-match "ends prematurely" (nth 1 err))) ;; ... or we were in a comment and just came out of ;; it. (and string-or-comment (not (nth 8 (syntax-ppss))))) (funcall at-top-level-or-equivalent-fn)) (t ;; exit the sexp (goto-char (nth 3 err)) (funcall ended-prematurely-fn))))) Also me :-) but I really have doubts I'm the only one.