Error handling meeting summary

[monkyyy]

On Friday, 25 July 2025 at 16:58:43 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> Hello all!
>
> We've had a meeting on how error handling should work in D.
>
> Approved work:
>
> - Finalisers are brought back to the baseline behaviour. They 
> will not be rewritten to sequences in the frontend. 
> https://github.com/dlang/dmd/blob/3d06a911ac442e9cde5fd5340624339a23af6eb8/compiler/src/dmd/statementsem.d#L3428
>
> - A CLI switch may be offered that performs rewriting of 
> finally statements to sequences if an ``Exception`` is not 
> thrown within the try body and finally statements will be 
> rewritten to ``catch(Exception)`` statements. This is Walter's 
> approach to error handling that he recommends. It cannot be 
> made the default as it will break language features.
>
> - A filter method is added to the ``Thread`` class hierarchy; 
> this filter method, by default, will call a grave digger global 
> function pointer if set. Otherwise, all ``Throwable``'s will 
> propagate like they do today.
>
>     It was considered that perhaps it would be a good idea to a 
> flag on ``Thread`` creation to determine if you want to kill 
> the process if ``Error`` is seen. No decision is made but I see 
> no reason a PR wouldn't be accepted if it only changes the 
> default behaviour of the filter method.
>
> I'm happy to do finally statement being brought back to 
> baseline, and filter method. However, it will be in the next 
> two months, not now. If someone wants to get to it before me 
> they may.
>
> Walter will have to do the CLI switch stuff, due to 
> intersecting with dmd's glue code.
>
> Approved work for someone who wants to do it:
>
> - A pragma within a function that disables unwinding. Requires 
> a DIP. Requires Iain&Martin's consultation.
>
> - Contracts being called in the caller, not callee. Walter 
> wants a DIP document to cover the current state (does not need 
> to go into the queue, it only has to exist). Timon offered to 
> do it. Anyone can implement as long as we get the document.
>
> - Null deref read barrier aka null check. CLI switch, throw 
> Error with a hook function. Noted that this is useful for 
> platforms like web assembly and debugging CI's where no stack 
> trace is present.
>
> Now for the trouble-making question, is there something that 
> people need that I haven't covered in these lists?

While adding flags that increase safety, consider adding flags 
that decrease safety. Maybe replace int/0=>int.max or maybe 
exceptions are just replaced with `return` and maybe half of 
phoboes io functions work as is or any of my other hottakes