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