RFC: Change what killing a thread does on error instead

[Richard (Rikki) Andrew Cattermole]

On 09/07/2025 8:24 AM, Sebastiaan Koppe wrote:
> On Tuesday, 8 July 2025 at 19:55:13 UTC, Dukc wrote:
>> 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.
> 
> That is similar to what happens with structured concurrency. For every 
> execution context there is always an owner to which any Error gets 
> forwarded to, all the way up to the main thread.
> 
> It would be straightforward to change that so that it terminates the 
> process on the spot, but I prefer graceful shutdown instead.

I've considered something like this, and I do think we need to make it 
configurable.

Have a method on a thread that "filters" by-ref any caught exception 
(Throwable) at the thread entry point.

Ideally the default is to kill the process, so that you don't have 
silent death of threads.

If you want to change it, you can override the method.

The default implementation could also check a global function pointer to 
do the grave digger concept of Dukc's.

I am concerned that to set such a default could break existing programs, 
so I'm not sure what to do about that.