From: "J.P." <jp@neverwas.me>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 67862@debbugs.gnu.org, Christian Ohler <ohler@gnu.org>
Subject: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug
Date: Fri, 02 Feb 2024 15:28:12 -0800 [thread overview]
Message-ID: <87ttmqh2er.fsf@neverwas.me> (raw)
In-Reply-To: <jwv1q9v8uh1.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Thu, 01 Feb 2024 21:46:32 -0500")
Stefan Monnier <monnier@iro.umontreal.ca> 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.
next prev parent reply other threads:[~2024-02-02 23:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-17 0:37 bug#67862: 30.0.50; Handler-bind and ert-test-error-debug Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-17 6:53 ` Gerd Möllmann
2023-12-17 15:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-26 16:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-26 18:00 ` Gerd Möllmann
2023-12-31 19:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-01 5:56 ` Gerd Möllmann
2024-01-01 12:15 ` Eli Zaretskii
2024-01-01 16:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-01 22:27 ` J.P.
2024-02-02 2:46 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-02 23:28 ` J.P. [this message]
2024-02-02 23:44 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttmqh2er.fsf@neverwas.me \
--to=jp@neverwas.me \
--cc=67862@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=ohler@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.