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