RFC: Change what killing a thread does on error instead
FeepingCreature
feepingcreature at gmail.com
Tue Jul 8 18:37:03 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.
>
I disagree. A *thread dying* should simply kill the program, no
matter for what reason it does. Threads dying not killing the
program by default is what's the problem here. If it was an
exception rather than AssertError, it'd be just as bad. We have
an internal thread implementation that does nothing but guarantee
that 1. the thread's error is logged, 2. the program goes down
immediately after.
More information about the Digitalmars-d
mailing list