From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Signaling errors within process sentinels only works when DEBUG-ON-ERROR is non-nil Date: Mon, 8 May 2023 20:07:37 -0500 Message-ID: <7692d504-0108-c68d-2608-8434f32b2025@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32361"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 09 03:08:24 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 1pwBq3-0008Bc-7q for ged-emacs-devel@m.gmane-mx.org; Tue, 09 May 2023 03:08:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pwBpU-0007bW-Nd; Mon, 08 May 2023 21:07:49 -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 1pwBpQ-0007ZI-Cn for emacs-devel@gnu.org; Mon, 08 May 2023 21:07:44 -0400 Original-Received: from black.elm.relay.mailchannels.net ([23.83.212.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwBpO-0004O5-21 for emacs-devel@gnu.org; Mon, 08 May 2023 21:07:44 -0400 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BBD4C641227 for ; Tue, 9 May 2023 01:07:38 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a290.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 508EA641B18 for ; Tue, 9 May 2023 01:07:38 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1683594458; a=rsa-sha256; cv=none; b=CfqZJlJkJ5C+QxkjuxjSvSF0LwusTRNJ1pB5gtSRVU+VLwvfBsz7fJrhFwBnGga7zGduFM IaKJMr2HTGOhUXNyi+sD/ceS1Y2bjwuyXDXtAy00q0qHJGeBnwz7nANY/9qXIY0ZNFC+wd +s0znFHYamPEgS7ICfVcI/49JcZ+Eriq2l3JK7Pc6qnyTDAZzPwLoSxQTZhEOfxTvfvQQp kk3rJE8KJZow+m1EJ1zm0LYCg+joU1ABb9ng2ed4XVKqNqTMkeb+0PbPDQ+suFS9omfAnX v6yn14dCtNtMBDTwE/GjuNTi//EpuDsxrwzHRl/6tXaV919mR30OZnaqsKmlJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1683594458; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=5dwvmMqXXultXhPWsQwpaDREcKh9dajXsG7UvPqDWBc=; b=+One/M0wIwMAo4BrEr0kCBfW7ErJgEGIsY8BKYx5r09ehDfdY0xdJxQ9sscUJZpYvX5IAV vkJwsv0PNRJpD0MbiG6CvVDSmMeH15w7dkb8FU5YSExrtZDozshRDiy4t6nhRFHLRtNoea a39sTWgi3b5ShCFHSlFqfH1s5tovlAn2r4Z4a1At6g5IZNKHa2h57607iVTx+k1pNjGXDz XIsuUeOcs3U8fcQhhS6DgbQQaeqIBtV+9Iq19HtGRcGvAbTMRTIN1eokdOlcDogF+64Qq5 newbeQ0FXCFh+uq0msk6ReNalQam36pDa0j8TKCHaOukVjIFxyAuUlg/jM91zw== ARC-Authentication-Results: i=1; rspamd-5cdf8fd7d9-t25ld; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Industry-Robust: 7b13ef4d5f400a13_1683594458548_646125232 X-MC-Loop-Signature: 1683594458548:662982019 X-MC-Ingress-Time: 1683594458548 Original-Received: from pdx1-sub0-mail-a290.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.116.217.237 (trex/6.7.2); Tue, 09 May 2023 01:07:38 +0000 Original-Received: from [10.45.1.6] (unknown [45.131.192.7]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a290.dreamhost.com (Postfix) with ESMTPSA id 4QFg4T6vKhz9x for ; Mon, 8 May 2023 18:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1683594458; bh=5dwvmMqXXultXhPWsQwpaDREcKh9dajXsG7UvPqDWBc=; h=Date:From:Subject:To:Content-Type:Content-Transfer-Encoding; b=tRu2Q0OT8o1OZHn94BxjgQIUfqMw56lV9bkN09svgkNdDxFSosTpfgum5ALK+F9uY /DFal4wUEeVLpQqY4jVMFfYop0rGz8zm/6HQZiEWOanA1Dd2vGeiwP9RfmB0XpKGUN abF2AK762yNuffVHF1670zEBnmuLTZf4Rl96Ead4AUnK2NsvuKLjtBP1vTtu4H9I3L twwOV3mL9E0buNhkbKl8I6ecBGhAF5pDBH7cOZ4VK2UE5FpHheLDoZsKP2YMBU8LkS i5sqqkTGqPb/YX5hQL+ZATATjmId6yOO9SqrOK0DfT6n4BBPKQHeXulpFrXoQTqOgp tV7kds9cSWZKw== Content-Language: en-US Received-SPF: neutral client-ip=23.83.212.19; envelope-from=adam@alphapapa.net; helo=black.elm.relay.mailchannels.net X-Spam_score_int: 20 X-Spam_score: 2.0 X-Spam_bar: ++ X-Spam_report: (2.0 / 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:305990 Archived-At: Hi, For a while now, in my work on plz.el[0], I've been trying to understand what causes an intermittent problem in that some HTTP requests sometimes return nil instead of the intended value. Some of my attempts are mentioned in plz.el#3[1], and that resulted in my filing Emacs bug#50166[2]. Finally, today I may have had a breakthough: I noticed that synchronous requests that are expected to signal an error which is intended to be handled by a CONDITION-CASE form do not have their error handled by the form; instead Emacs seems to intercept the error itself, and so the value that the CONDITION-CASE would return is not returned, with NIL being returned instead. For example, see this code: (condition-case err (plz 'get "https://httpbinnnnnn.org/get/status/404") (error 'foo)) This makes an HTTP request to a non-existent domain name, for which plz signals an error in the process sentinel. However, when evaluating this form (with EVAL-EXPRESSION-DEBUG-ON-ERROR set to NIL), instead of evaluating to 'FOO, I get this in the *Messages* buffer: error in process sentinel: plz: Curl error: "plz--sentinel: Curl error", #s(plz-error (6 . "Couldn't resolve host. The given remote host was not resolved.") nil nil) nil 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)? 2. Are there any potential problems with this workaround? 3. Is there a better way? 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. 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. 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? Thanks, Adam 0: https://github.com/alphapapa/plz.el 1: https://github.com/alphapapa/plz.el/issues/3 2: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50166 3: https://github.com/tkf/emacs-request/blob/01e338c335c07e4407239619e57361944a82cb8a/request.el#L1146