[RFC] Throwing an exception with null pointers

[Derek Fawcus]

On Saturday, 12 April 2025 at 23:11:41 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> I've been looking once again at having an exception being 
> thrown on null pointer dereferencing.
> However the following can be extended to other hardware level 
> exceptions.
>
> I do not like the conclusion, but it is based upon facts that 
> we do not control.
>
> ## Conclusion
>
> We cannot rely upon hardware or kernel support for throwing of 
> a null pointer exception.
> To do this we have to use read barriers, like we do for array 
> bounds check.
>
> There are three levels of support needed:
>
> 1. Language support, it does not alter code generation, 
> available everwhere.
>     Can be tuned to the users threshold of pain and need for 
> guarantees.
> 2. Altering codegen, throws an exception via a read barrier 
> just like a bounds check does.
> 3. Something has gone really wrong and CPU has said NOPE and a 
> signal has fired to kill the process.

 From the unix/posix perspective, I'd say don't even try.  Just 
allow the signal (SIGSEGV and/or SIGBUS) to be raised, not 
caught, and have the process crash.  Debugging then depends upon 
examining the corefile, or using a debugger.

The only gain from catching it is to generate some pretty form of 
back trace before dying, and that is just as well (or better) 
handled by a debugger, or an external crash handling and 
backtrace generating corset/monitor/supervision process.

Once one catches either of these signals, one has to be very 
careful in handling if any processing is to continue beyond the 
signal handler.  With a complex runtime, and/or a multi-threaded 
application, it often isn't worth the effort.