RFC: Change what assert does on error

Sebastiaan Koppe mail at skoppe.eu
Mon Jun 30 21:18:42 UTC 2025


On Sunday, 29 June 2025 at 18:04:51 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> Hello!
>
> I've managed to have a chat with Walter to discuss what assert 
> does on error.
>
> In recent months, it has become more apparent that our current 
> error-handling behaviours have some serious issues. Recently, 
> we had a case where an assert threw, killed a thread, but the 
> process kept going on. This isn't what should happen when an 
> assert fails.
>
> An assert specifies that the condition must be true for program 
> continuation. It is not for logic level issues, it is solely 
> for program continuation conditions that must hold.
>
> Should an assert fail, the most desirable behaviour for it to 
> have is to print a backtrace if possible and then immediately 
> kill the process.
>
> What a couple of us are suggesting is that we change the 
> default behaviour from ``throw AssertError``.
> To: ``printBacktrace; exit(-1);``
>
> There would be a function you can call to set it back to the 
> old behaviour. It would not be permanent.
>
> This is important for unittest runners, you will need to change 
> to the old behaviour and back again (if you run the main 
> function after).
>
> Before any changes are made, Walter wants a consultation with 
> the community to see what the impact of this change would be.
>
> Does anyone have a case, implication, or scenario where this 
> change would not be workable?
>
> Destroy!

Please don't make this the default. It's  wrong in 99% of the 
cases.

For those whom this is important just allow them to hook things 
if they care about it. Just know that the idea of exiting 
directly when something asserts on the pretense that continueing 
makes things worse breaks down in multi-threaded programs. All 
other threads in the program will keep running until that one 
thread finally ends up calling abort, but it might very well be 
suspended on between printbackTrace and abort; it's completely 
non-deterministic.

For all others, use a sane concurrency library that catches them 
and bubbles them up to the main thread.


More information about the Digitalmars-d mailing list