From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug Date: Fri, 02 Feb 2024 15:28:12 -0800 Message-ID: <87ttmqh2er.fsf@neverwas.me> References: <87o7czkegk.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4535"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 67862@debbugs.gnu.org, Christian Ohler To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 03 00:29:09 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 1rW2y4-0000yp-VL for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 03 Feb 2024 00:29:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rW2xp-0008Gw-AL; Fri, 02 Feb 2024 18:28:53 -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 1rW2xn-0008Go-RJ for bug-gnu-emacs@gnu.org; Fri, 02 Feb 2024 18:28:51 -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 1rW2xn-0007Sw-J7 for bug-gnu-emacs@gnu.org; Fri, 02 Feb 2024 18:28:51 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rW2xy-0008CX-8L for bug-gnu-emacs@gnu.org; Fri, 02 Feb 2024 18:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Feb 2024 23:29: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.170691651731493 (code B ref 67862); Fri, 02 Feb 2024 23:29:02 +0000 Original-Received: (at 67862) by debbugs.gnu.org; 2 Feb 2024 23:28:37 +0000 Original-Received: from localhost ([127.0.0.1]:45660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rW2xY-0008Bs-Nb for submit@debbugs.gnu.org; Fri, 02 Feb 2024 18:28:37 -0500 Original-Received: from mail-108-mta94.mxroute.com ([136.175.108.94]:40491) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rW2xW-0008Bi-9g for 67862@debbugs.gnu.org; Fri, 02 Feb 2024 18:28:35 -0500 Original-Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta94.mxroute.com (ZoneMTA) with ESMTPSA id 18d6c26d52b0003727.001 for <67862@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 02 Feb 2024 23:28:20 +0000 X-Zone-Loop: c6af112d8b5d2ae530fac81ed1f0dcc51106b02b15fc X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=U1dzNrSU6iYjDdOlO2hG9Q2Gk86uqFzcaShRuqeDlE8=; b=HjK+K3lcBSTcOR+unOaowb7NvB T4yLzd6eExv2wF3CBl1R8rSeYNakb/yh9AR6Dz08eOJXNKGx7sFh6wuWc2OWLcMj5wuCytRBghDej oMHdI7QTBcP5w+xiGOrZghEMdcTphSYYuT800EI4MODMmUuW4b8GVoLOWEGCqtJZhsqp2cZODfnXw vqy81WOm3b9ZNPzHPeYKWFTnY7qfSEMpHK9EzSfBzgSV3/KIsqt1u5jxL1emmTh401gk3NgjVP3eb 83Q5nX2jV3T6HTQylyd572pxjMiiqaiiuhodi4KU5NFfYtiI2Hov3s2osMlNci+dFjjd9Hjr2jgVY AtK5KppA==; In-Reply-To: (Stefan Monnier's message of "Thu, 01 Feb 2024 21:46:32 -0500") X-Authenticated-Id: masked@neverwas.me 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:279355 Archived-At: Stefan Monnier writes: > - 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. Appreciate the insight re `debug-on-error'. Indeed, running `my-filter' with the variable enabled regains the original behavior WRT the backtrace, the summary, and the exit code. And I suppose those worried about such details (like ERC's bot, which depends on JUnit reports from EMBA pipelines) can just enable it themselves. > > For `my-timer`, on the other hand, hmm... For this one, enabling `debug-on-error' at least seems to restore the original behavior in terms of exiting nonzero, which should free users from having to grep for "Error running timer" in the output of passing tests. -*- mode: compilation; default-directory: "~/emacs/master/test/" -*- Compilation started at Fri Feb 2 14:51:58 make lisp/emacs-lisp/ert-tests.log ELC+ELN lisp/emacs-lisp/ert-tests.elc GEN lisp/emacs-lisp/ert-tests.log Running 1 tests (2024-02-02 14:52:02-0800, selector `my-timer') Debugger entered--Lisp error: (error "Encountered a problem") error("Encountered a problem") (closure (ert--test-body-was-run t) nil (error "Encountered a problem"))() apply((closure (ert--test-body-was-run t) nil (error "Encountered a problem")) nil) [...] ert-run-tests-batch(my-timer) ert-run-tests-batch-and-exit(my-timer) eval((ert-run-tests-batch-and-exit 'my-timer) t) command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/emacs-lisp/ert-tests.el" "--eval" "(ert-run-tests-batch-and-exit (quote my-timer))")) command-line() normal-top-level() make: *** [Makefile:181: lisp/emacs-lisp/ert-tests.log] Error 255 Compilation exited abnormally with code 2 at Fri Feb 2 14:52:02, duration 4.30 s I guess folks who depend on these always running to completion will still have to adapt a bit, but in light of this workaround, I'd say these changes are much less disruptive than originally feared, which is a welcome relief. Thanks.