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#67862: 30.0.50; Handler-bind and ert-test-error-debug Date: Thu, 01 Feb 2024 21:46:32 -0500 Message-ID: References: <87o7czkegk.fsf@neverwas.me> 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="4248"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 67862@debbugs.gnu.org, Christian Ohler To: "J.P." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 02 03:47:11 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 1rVjaA-0000te-Ub for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 02 Feb 2024 03:47:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rVjZw-00088f-5H; Thu, 01 Feb 2024 21:46:56 -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 1rVjZs-00088H-Af for bug-gnu-emacs@gnu.org; Thu, 01 Feb 2024 21:46:52 -0500 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 1rVjZs-0000Aj-2S for bug-gnu-emacs@gnu.org; Thu, 01 Feb 2024 21:46:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rVja2-0007OH-4V for bug-gnu-emacs@gnu.org; Thu, 01 Feb 2024 21:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Feb 2024 02:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67862 X-GNU-PR-Package: emacs Original-Received: via spool by 67862-submit@debbugs.gnu.org id=B67862.170684201828399 (code B ref 67862); Fri, 02 Feb 2024 02:47:02 +0000 Original-Received: (at 67862) by debbugs.gnu.org; 2 Feb 2024 02:46:58 +0000 Original-Received: from localhost ([127.0.0.1]:43389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVjZx-0007Nz-HU for submit@debbugs.gnu.org; Thu, 01 Feb 2024 21:46:57 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4254) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVjZs-0007Ni-0f for 67862@debbugs.gnu.org; Thu, 01 Feb 2024 21:46:56 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7E0301003D2; Thu, 1 Feb 2024 21:46:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706841994; bh=kH97s4wtVtR3tKYBPlKzDQmlfCrqd22zhfxtYYSvp8k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=o+u02cADX/95O/Pz1Vp2C3nNe7BJOx418QLEYqHEaBF49hr/pauJ6IqOcR2jQH6Tg 25E8zQyLMS8/zCDmCk7xVRForfg7gNzQmvPYokEA4i3h+0HgHgp31I2ekW7MlF73am 0hzxRNIDdnNsaYSpA9pIs+keLHWJACoFvZAilzCQgZQxt8w8f5qIC2Gc2QrQ0H1V57 3yCgMwYJHKU2oV4pEyHC3H/bl3EoPA9OxTvDZv3zsUPXao/0RiyI5LZkdQ02fBGGXT e0ddVX4iwOlYTSrd2Z7WvOPvQfxbpcGd2ul6BI+80++sSELzBCBaxsi6AQdCCplNBB /GsaBdIwWF0ww== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5395D1003AF; Thu, 1 Feb 2024 21:46:34 -0500 (EST) Original-Received: from pastel (69-165-153-17.dsl.teksavvy.com [69.165.153.17]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2539612025D; Thu, 1 Feb 2024 21:46:34 -0500 (EST) In-Reply-To: <87o7czkegk.fsf@neverwas.me> (J. P.'s message of "Thu, 01 Feb 2024 14:27:23 -0800") 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:279313 Archived-At: Hi J.P., > (ert-deftest my-baseline () > (error "Done wrong")) > > (ert-deftest my-filter () > (let ((proc > (start-process "my-filter" (current-buffer) "sh" "-c" > "for i in $(seq 99); do echo $i; sleep 0.01; done"))) > (set-process-filter proc > (lambda (_ string) > (when (string-search "42" string) > (error "Encountered bad value")))) > (with-timeout (5 (ert-fail "Timed out")) > (while (process-live-p proc) > (accept-process-output nil 0.01))))) > > (ert-deftest my-timer () > (run-at-time 0.2 nil (lambda () (error "Encountered a problem"))) > (with-timeout (5 (ert-fail "Timed out")) > (while (accept-process-output nil 5)))) Thanks. Indeed, `handler-bind` behaves differently than `debug-on-error` here. The reason is: - For `my-filter`, process.c:6329 it's the `!NILP (Vdebug_on_error)` test in: internal_condition_case_1 (read_process_output_call, list3 (outstream, make_lisp_proc (p), text), !NILP (Vdebug_on_error) ? Qnil : Qerror, read_process_output_error_handler); - For `my-timer`, it's the `condition-case-unless-debug` in timer.el:319: (condition-case-unless-debug err ;; Timer functions should not change the current buffer. ;; If they do, all kinds of nasty surprises can happen, ;; and it can be hellish to track down their source. (save-current-buffer (apply (timer--function timer) (timer--args timer))) (error (message "Error running timer%s: %S" (if (symbolp (timer--function timer)) (format-message " `%s'" (timer--function timer)) "") err))) The reason to catch errors in those two cases is that these codes are normally run asynchronously, so it makes sense to catch errors rather than propagate them up to some unrelated ambient code being executed. For `my-filter` I can see a good argument that errors should be propagated when you pass `proc` explicitly to `accept-process-output` and the filter/sentinel that signals the error is indeed this very process: in that case, there is a very clear connection between the filter/sentinel and the ambient code which would justify propagating the error. For `my-timer`, on the other hand, hmm... Stefan