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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 09 Mar 2025 10:38:55 +0200

> Cc: [email-masked], [email-masked], [email-masked],
>  [email-masked]
> Date: Fri, 21 Feb 2025 09:01:09 +0200
> From: Eli Zaretskii <[email-masked]>
> 
> > 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?

No further comments, so I presume the bug was fixed, and I'm therefore
closing it.