RFC: Change what killing a thread does on error instead

[Dukc]

On Tuesday, 8 July 2025 at 18:37:03 UTC, FeepingCreature wrote:
> 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.

That's an interesting idea actually. I think we still should have 
some mechanism for another thread to handle a thread death but 
maybe catching another error at another thread isn't the way.

Instead, maybe some thread could register a death handler 
delegate (thread gravedigger?) that is called if another thread 
dies. If there is no gravedigger, or if the only gravedigger 
thread itself dies, then all others would immediately receive an 
unrecoverable error, and the error from the dead thread would be 
what is reported.