[RFC] Throwing an exception with null pointers

[Richard (Rikki) Andrew Cattermole]

On 15/04/2025 2:55 AM, Arafel wrote:
> I mean, a service can fail for a number of reasons, including hardware 
> issues, among which dereferencing a null pointer should be quite low in 
> the scale of probabilities.

It isn't a low probability.

The reason why all these application VM languages have been introducing 
nullability guarantees, is because it has been a plague of problems.

We have nothing currently.

“I call it my billion-dollar mistake. It was the invention of the null 
reference in 1965. At that time, I was designing the first comprehensive 
type system for references in an object oriented language (ALGOL W). My 
goal was to ensure that all use of references should be absolutely safe, 
with checking performed automatically by the compiler. But I couldn't 
resist the temptation to put in a null reference, simply because it was 
so easy to implement. This has led to innumerable errors, 
vulnerabilities, and system crashes, which have probably caused a 
billion dollars of pain and damage in the last forty years.”

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

> Having a 1M$/day operation depend on your application's continued run 
> after dereferencing a null pointer would seem to me... rather risky and 
> sort-sighted.

You need to read my initial post. I concluded that once an instruction 
executes the dereference it is in fact dead. We are not in disagreement 
in terms of this.

This is why the static analysis and read barrier is so important, they 
catch it before it ever happens. The program isn't corrupted by the 
signal at this point in time.

Before that, thanks to ``@safe``, we can assume it is in a valid state, 
and its just business logic that is wrong. Yes people will disagree with 
me on that, but the blame is purely on the non- at safe code which should 
be getting thoroughly vetted for this kind of thing (and even then I 
still want the read barriers and type state analysis to kick in, because 
this can never be correct).

There is a reason why my DIP makes stackless coroutines default to 
@safe, not just allow you to default to @system like everything else.

> On top of that, there's the "small" issue that you can't really be sure 
> what state the application has been left in. I certainly wouldn't want 
> to risk any silent data corruption and would rather kill the process 
> ASAP to start it again from a known good state.

By doing this you have killed all other tasks, those tasks make you lose 
money. Throw in say a scrapper and you could still be down all day or 
more. It is an entirely unnecessary downtime with accepted widely used 
solutions. It would be bad engineering to ignore this.

It is important to note that a task isn't always a process. But once an 
event like null dereference occurs that task must die.

If anything prevents that task from cleaning up, then yes the process dies.