[RFC] Throwing an exception with null pointers

[Richard (Rikki) Andrew Cattermole]

On 14/04/2025 1:07 AM, Derek Fawcus wrote:
> 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.

This is how it is implemented currently.

Which is don't touch it and it matches my analysis.