Subject: bug#11218: with-demoted-errors use of condition-case-unless-debug; ert

From: Eli Zaretskii <[email-masked]>
Date: Fri, 21 Feb 2025 09:01:09 +0200

> Cc: [email-masked], Stefan Monnier <[email-masked]>,
>  Christian Ohler <[email-masked]>
> From: Philipp Stephani <[email-masked]>
> Date: Thu, 20 Feb 2025 21:31:57 +0100
> 
> 
> 
> > Am 24.11.2020 um 18:34 schrieb Philipp Stephani <[email-masked]>:
> > 
> > Am Mi., 15. Aug. 2018 um 03:11 Uhr schrieb Noam Postavsky <[email-masked]>:
> >> 
> >> Christian Ohler <[email-masked]> writes:
> >> 
> >>> On 4/13/12 6:44 AM, Stefan Monnier wrote:
> >>>>>>> If you replace with-demoted-errors with ignore-errors, the test passes.
> >>>>>> Looks like a bug in ERT.
> >>>>> I don't know if it's a "bug" per se...
> >>>>> ert--run-test-internal binds debug-on-error to t, and redefines the
> >>>>> debugger to ert--run-test-debugger. As the doc of that function says:
> >>>> 
> >>>> I wonder why ERT doesn't just use condition-case to catch and record
> >>>> the errors.
> >>> 
> >>> Two reasons that I remember off the top of my head: Recording
> >>> backtraces, and recording additional information provided with
> >>> `ert-info'.  Using condition-case would let ERT regain control only
> >>> after the stack is unwound, at which point that information is gone.
> >> 
> >> I just posted a patch which changes ERT to use `signal-hook-function' to
> >> record backtraces instead.  It fixes the case in the OP.
> >> 
> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30745#20
> >> 
> >> Note that condition-case also needs an enhancement to be able to catch
> >> any signal (Bug#24618), so that might be a third reason why ERT didn't
> >> go this route originally.
> >> 
> > 
> > This issue continues to bug me because normal and expected use of
> > with-demoted-errors in (unrelated) libraries breaks tests in annoying
> > ways. Is there any way I can help move this forward? Is your patch
> > still blocked on anything?
> 
> This has probably been fixed by commit fe0f15dbc962b37d98507a494fd7720bad584a7a.

Thanks, but what does "probably" mean in this case?  Can we close the
bug, or is there anything left to do here?