RFC: Change what assert does on error

[Timon Gehr]

On 7/4/25 21:42, Dennis wrote:
> On Friday, 4 July 2025 at 18:49:50 UTC, Timon Gehr wrote:
>> With: It writes a file with the full interaction log that leads to the 
>> crash. The user can see the stack trace in a console window that is 
>> kept open using `system("pause")`.
>> (...)
>> Without: The program randomly closes on the user's machine and I get 
>> no further information.
> 
> Correct me if I'm wrong, but this is responding to the opening question 
> of `throw AssertError` vs `printBacktrace; exit(-1);` right? Rikki's and 
> Jonathan's current proposition is that `finally` blocks must still 
> always be executed when an `Error` bubbles up through a `nothrow` 
> function, for better error logging. Your custom assert handler is nice, 
> but would work just as well when a couple of destructors are skipped as 
> far as I can tell.

Skipping destructors may leave the program in an inconsistent and 
unpredictable state, including memory corruption due to lack of cleanup 
of stack pointers. I don't want destructors and finally blocks to have 
distinct behavior. It may sometimes lead to problems while at the same 
time not addressing any need that I have.

It is also a key pitfall for data structures with `@trusted` behaviors. 
Anyone anywhere will have to assume that destructors are not guaranteed 
to run for stack-allocated variables.

This would be less of a problem if there were at least a way to turn off 
nothrow inference, but even when there is nothrow inference, eliding 
destructor calls is just not a need I have and it seems like an unsafe 
default behavior.

It would be better to just disallow variables with destructors in 
nothrow functions.

Anyway, this is not only about asserts, and it is not specific to 
asserts. E.g. a RangeError is the same kind of problem and it is handled 
the same way.