What should happen when the assert message expression throws?

[Ali Çehreli]

On 11/25/22 05:32, kdevel wrote:
 > On Friday, 25 November 2022 at 12:29:26 UTC, Ali Çehreli wrote:
 >
 >> According to common assert wisdom, the program must not continue once
 >> an assertion has failed because the program is in invalid state.
 >
 > Whatever "invalid state" means. I could not find a definition in the
 > manual.

The assertion check defines the legal state. Its failure is the invalid 
state:

     int a = 42;
     foo(&a);
     assert(a == 42);

The programmer defined the valid state of the program as being "when I 
pass 'a' by reference to 'foo', its value shall remain 42."

If that assertion fails, the program is in an invalid state.

 >> However, the main thread of a D program does execute code to display
 >> the backtrace to help the programmer discover why the assertion
 >> failed. By the wisdom above, this is best-effort because if the
 >> program is in an invalid state, the code that attempts to display the
 >> backtrace can e.g. delete files.
 >
 > Pardon! What?

Assume the assertion failure was an indication of a catastrophic event, 
which overwrote a function pointer that will end up executing unrelated 
code that deletes files.

 >> I had discovered that fact when I first started catching Errors in
 >> non-main threads to do exactly what the main thread does. I used to
 >> feel guilty about that but now I know it's all best-effort anyway: it
 >> may or may not work.
 >>
 >> Add to the above another observation which I had after Patrick
 >> Schluter's message: Even the execution of the assert check is
 >> best-effort because if the check will fail, the program has been in
 >> invalid state for an unknow amount of time anyway.
 >
 > int main ()
 > {
 >     int a = 1;
 >     try
 >        assert (a == 0);
 >     catch (Throwable t)
 >        {}
 >     return 0;
 > }
 >
 > Which line makes the program enter the "invalid state"?

Although that looks like a bug in the programmer's mind, I can still 
imagine the programmer expected some code perhaps running in a thread 
started e.g. in a 'static this' block was expected to alter the stack. 
It must be in an operating system that guarantees that other thread is 
executed so frequently that even after assigning 1 to a, it is expected 
to be observed as 0.

There: The programmer knew things we don't see.

If that was the entirety of the program, then I think the programmer is 
wrong.

 > Additional
 > question: What constitutes that "invalid state"?

I have to trust the assertion check, which may be buggy itself.

Ali