From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#72212: 31.0.50; API for condition objects Date: Sat, 02 Nov 2024 15:37:59 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18999"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 72212@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 02 20:39:25 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1t7Jy1-0004kO-Cw for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Nov 2024 20:39:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t7Jxh-00006A-GD; Sat, 02 Nov 2024 15:39:05 -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 1t7Jxe-000059-CC for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2024 15:39:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t7Jxe-0007Df-3g for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2024 15:39:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=8NRUSp0/Vwz32PPv6Tp6E48u3D9uXCjrl9o8ZaHew9M=; b=qkI7hoTs/inSCNI1M05SOkQOreWPbPVu+looAubLWk8bPN0KDImo44mjMYcV22ksqYYcBKosZj8TsCqimRnh5QsIRKIDuvTaObhNYUVB6tUnwOr6lqdbfg2i+R47yHoljfFPm5d3y/BATSOyUnu2iGhBCgQVxE6nwvgq3LnUHvZiSmPnCcY4BQLxImPVlL9sOV/kFivkEoROFu3NS55xh7ulyudwaXwrH5xbeFv0vg8xzByt6JkELuyn7ljVY+1kIHitEkmxOX/e3OP9GZUtU0mTFD5AttU+ECn/4lgX4ZadMpsA0zl33pcvzpt8UOP67BbREK0HfW2JtSoFQEE7kQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t7Jxd-0006IS-Te for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2024 15:39:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Nov 2024 19:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72212 X-GNU-PR-Package: emacs Original-Received: via spool by 72212-submit@debbugs.gnu.org id=B72212.173057629724182 (code B ref 72212); Sat, 02 Nov 2024 19:39:01 +0000 Original-Received: (at 72212) by debbugs.gnu.org; 2 Nov 2024 19:38:17 +0000 Original-Received: from localhost ([127.0.0.1]:55241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7Jwv-0006Hy-AA for submit@debbugs.gnu.org; Sat, 02 Nov 2024 15:38:17 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7Jws-0006Ho-H4 for 72212@debbugs.gnu.org; Sat, 02 Nov 2024 15:38:15 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1B7BD80821; Sat, 2 Nov 2024 15:38:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730576286; bh=xSxjc8yC+AE+gmMzDAYvJq59eDdNy/oosbxsRd0F2JQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QpBkaPlMDTKUXfMz7A+vpyxtdkjt3/A+ZhBY6rFMUr7G8WvUB3FrT8j7rl7uN2bhb ooqCI/NlOxZbosFEvzeoUSUDB4eiol6rCdZHV5pt/jBHbcrHNR3xz+2daR/RFS6h01 PtOlSPNb5BYu5hIoctpzCwW42CuVj+IKhVtLsNl1Kob+i+qDG47csICVo11HIrVNI+ Aiz2OGPZWYKjMgdMcqig7eDljmZsKVXVAwCEinEC1CuSBbrt7A3Ui9yXH0WEy9fNcJ FedtTZfvZfjAIIFDYiOgamw+Ar5EmGb6v14lmEp7IKxS8G9BWldj8JDKbx2Ct+sKI3 D/NDim6SmbvlA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DBA3C80024; Sat, 2 Nov 2024 15:38:06 -0400 (EDT) Original-Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AEA6A12038D; Sat, 2 Nov 2024 15:38:06 -0400 (EDT) In-Reply-To: (Stefan Kangas's message of "Sat, 14 Sep 2024 17:09:09 -0700") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:294772 Archived-At: >>> Beside whether we want to do this or not, there is another question >>> about naming: currently we use "condition" in some places (e.g. in >>> `condition-case`) but we use "error" in others (e.g. `define-error` and >>> `error-message-string`). > I think we should keep the word "condition", and think we could have > aliases "define-condition" and "condition-message-string" like you > propose. >From the code's point of view, this works OK, except I noticed that it conflicts with the notion of "condition" used in the threading code (as in `condition-wait`, `condition-variable-p`, ...), but on the manual side it's quite a different story, because there we "systematically" use the term "error", e.g.: @node Errors @subsection Errors @cindex errors When Emacs Lisp attempts to evaluate a form that, for some reason, cannot be evaluated, it @dfn{signals} an @dfn{error}. When an error is signaled, Emacs's default reaction is to print an error message and terminate execution of the current command. This is the right thing to do in most cases, such as if you type @kbd{C-f} at the end of the buffer. In complicated programs, simple termination may not be what you want. For example, the program may have made temporary changes in data structures, or created temporary buffers that should be deleted before the program is finished. In such cases, you would use @code{unwind-protect} to establish @dfn{cleanup expressions} to be evaluated in case of error. (@xref{Cleanups}.) Occasionally, you may wish the program to continue execution despite an error in a subroutine. In these cases, you would use @code{condition-case} to establish @dfn{error handlers} to recover control in case of error. For reporting problems without terminating the execution of the current command, consider issuing a warning instead. @xref{Warnings}. Resist the temptation to use error handling to transfer control from one part of the program to another; use @code{catch} and @code{throw} instead. @xref{Catch and Throw}. @menu * Signaling Errors:: How to report an error. * Processing of Errors:: What Emacs does when you report an error. * Handling Errors:: How you can trap errors and continue execution. * Error Symbols:: How errors are classified for trapping them. @end menu Here are options, I can see: - Change the manual's text to use "condition" instead of "error" pretty much everywhere. - Use a naming based on `error` instead of `condition` (optionally with `error-case(-unless-debug)` as aliases for `condition-case`?). - Keep a mix, where we add to the manual a paragraph explaining that `signal` really causes a "condition" but that most conditions (tho not all, `quit` being the main(sole?) exception) are subtypes of the `error` condition so we usually refer to conditions as "errors". I'm leaning towards the third option, because I think straightening out the mix of "conditions" and "errors" we have is fairly difficult. Stefan