RFC: Change what assert does on error

[Dennis]

On Saturday, 5 July 2025 at 07:07:00 UTC, Jonathan M Davis wrote:
> If a mutex is locked and freed using RAII (or scope statements 
> are used, and any of those are skipped), then you could get 
> into a situation where a lock is not released like it was 
> supposed to be, and then code higher up the stack which does 
> run while the stack is unwinding attempts to get that lock

Why would your crash handler infinitely wait on one of your 
program's mutexes? I'd design a crash reporter for a UI 
application as follows:

- Defensively collect traces/logs up to the point of the crash
- Store it somewhere
- Launch a separate process that lets the user easily send the 
data to the developer
- Exit the crashed program

I think that's how most work on 
https://en.wikipedia.org/wiki/Crash_reporter
Except that they don't even collect the data inside the crashed 
program, but let the crash handler attach a debugger like gdb to 
the process and collect it that way, which is even more defensive.

I still don't see how a missed scope(exit)/destructor/finally 
block (they're interchangable in D) not putting the hourglass 
cursor back to a normal cursor on the crashed window would hurt 
the usability of a crash handler, or the quality of the log.