From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Signaling errors within process sentinels only works when DEBUG-ON-ERROR is non-nil Date: Tue, 09 May 2023 10:08:52 +0300 Message-ID: <83ild2asmz.fsf@gnu.org> References: <7692d504-0108-c68d-2608-8434f32b2025@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38053"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 09 09:08:33 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 1pwHSa-0009dM-0G for ged-emacs-devel@m.gmane-mx.org; Tue, 09 May 2023 09:08:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pwHRw-0007zy-6b; Tue, 09 May 2023 03:07:52 -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 1pwHRu-0007zZ-Ta for emacs-devel@gnu.org; Tue, 09 May 2023 03:07:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwHRu-0006gg-Fg; Tue, 09 May 2023 03:07:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=vx/ZEaZm6y/OqCh+g1KjpG06ydasLCN2q5A7/j5sHog=; b=hrXZ6SNox4zFYUR+RL70 +Sv7UpxA8Nvcv6AvxfEay+lQdD35syrhaMq6WmSEl7CAfYZD6E9fmxqUw3q/hTdCb/lV8oeOPxEBD 46WNnZyLN9h4qiI8j7BntXlT1WfZG8HJ2C7TklmdJwNYzoOK3gORj7AhV5FOOZn2C+OeQEPGOj0Cf CTxOraP/LGw1YlgTduVtVj23zioC0LYmMM3pyuqPYnKEkVZJdq/GxjODPMrlRRzIgeLvAAG9ggSkN 99vnY78VGQpAO2zus47w1RVrtgsHsPZpLHLurs55h+ngEU5HgHoIP39kC2CAVdvGMb3Xv5P9LXMGm G5hvCKRc//zW3A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwHRt-0000W9-US; Tue, 09 May 2023 03:07:50 -0400 In-Reply-To: <7692d504-0108-c68d-2608-8434f32b2025@alphapapa.net> (message from Adam Porter on Mon, 8 May 2023 20:07:37 -0500) 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:305996 Archived-At: > Date: Mon, 8 May 2023 20:07:37 -0500 > From: Adam Porter > > The CONDITION-CASE is apparently not allowed to handle the error, and > NIL is returned instead of 'FOO (after the 2-second > process-sentinel-error delay, which I also learned about recently, which > Lars recently added a variable to control). > > In re-reading the Info page `(elisp)Sentinels', I saw this: > > If an error happens during execution of a sentinel, it is caught > automatically, so that it doesn’t stop the execution of whatever > programs was running when the sentinel was started. However, if > ‘debug-on-error’ is non-‘nil’, errors are not caught. > > So I tried binding DEBUG-ON-ERROR non-nil around the call to PLZ, and > sure enough, this solved the problem: > > (let ((debug-on-error t)) > (condition-case err > (plz 'get "https://httpbinnnnnn.org/get/status/404") > (error 'foo))) > > That evaluates to 'FOO, immediately, as expected. > > So my questions: > > 1. Is this an acceptable way to work around this problem (of not being > "allowed" to signal errors within a process sentinel)? I think it is not very clean. debug-on-error is not supposed to be set by Lisp programs, unless the Lisp program is itself used for debugging something. > 2. Are there any potential problems with this workaround? Yes. For starters, you will break any use case where a user or a Lisp program wants to know about any *real* errors in your sentinel code, because when they set debug-on-error non-nil, the error will not propagate all the way to top level or to a signal handler installed by higher-level callers. > 3. Is there a better way? Yes: don't design a sentinel that signals an error. Why is that necessary? I'm guessing you did that out of some convenience, not because there are no other ways of handling those situations. In general, code running in the background should not signal errors it doesn't itself catch, except when there are situations it cannot possibly handle by itself. > 4. Should Emacs be patched to change this behavior? It seems strange to > me that, unless a seemingly unrelated variable is bound, errors within > sentinels can't be caught by CONDITION-CASE forms enclosing the code > that signals the error. debug-on-error is not "unrelated". We pay attention to it so as to allow debugging of sentinels, which would otherwise be nigh impossible to do on the Lisp level. > FWIW, I have spent many hours of apparently wasted time trying to debug > this, what has seemed to be a mysterious problem. Admittedly, this has > been documented in the manual for quite some years, and I've read that > page many times, but it wasn't until today that I was able to recognize > what was happening in the code and connect the behavior with that > paragraph in the manual. So if Emacs could be made to behave more > "naturally" in this respect, it would probably be widely useful. I think what Emacs does today is very natural: we are running arbitrary Lisp asynchronously, which could be in the middle of an arbitrary foreground Lisp program. E.g., imagine that Emacs just prompted the user for something in the minibuffer and is waiting for the user to type a complete response to the prompt -- how can we allow a sentinel that happens to run at that time to signal an error? that could error out of the command which prompted the user! It is basically the same situation as calling some Lisp hook from redisplay: it isn't a coincidence that redisplay calls such hooks in a similar manner, catching all errors and logging the information about them in *Messages*. > As a point of comparison, request.el, the popular HTTP library for > Emacs, seems to work around this by catching errors in a function called > from within the sentinel and returning a list including the error data, > rather than allowing the signal to propagate up to application code[3]. > This certainly works, but it seems unnatural; wouldn't it be preferable > to allow callers to wrap the call in their own CONDITION-CASE? IMO, what request.el does is _exactly_ what a sentinel should do when it wants to handle an error signaled by its code or by one of its subroutines. It is not "unnatural", it is what every sentinel (and filter function as well) should do, because signaling errors from asynchronous code is a very bad idea.