[RFC] Throwing an exception with null pointers

[Richard (Rikki) Andrew Cattermole]

On 15/04/2025 3:42 AM, Derek Fawcus wrote:
> On Monday, 14 April 2025 at 15:24:37 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>>
>> 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.
> 
> It is not the dereference which is the issue, that is the downstream 
> symptom of an earlier problem.  If that reference is never supposed to 
> be null, then the program is already in a non deterministic even without 
> the crash.

You are not the first to say this, and its indicative of not 
understanding the scenario.

Coroutines are used for business logic.

They are supposed to have guarantees where they can always be cleaned up 
on framework level exceptional events. That includes attempts at null 
dereferencing or out of bounds access of slices.

They should never have the ability to corrupt the entire program. They 
need to be @safe.

If @safe allows program corruption, then it needs fixing.

If you call @trusted code that isn't shipped with the compiler, that 
isn't our fault it wasn't vetted. But that is what it is exists for. So 
that you can do unsafe things and present a safe API.

Any other scenario than coroutines will result in a process death.

> The crash is what allows that bad state to be fixed.  Simply limping 
> along (aoiding the deref) is sweeping the issue under the rug.  One 
> doesn't know what else within the complete system is at fault.

Except it isn't the entire system that could be bad.

Its one single threaded business logic laden task. It is not library or 
framework code that is bad.

A single piece of business logic, that was written likely by a graduate 
level skilled person, failed to account for something.

This is not the same thing as the entire program being corrupt.

If some kind of coroutine isn't in use, the program still dies, just 
like today.

> The @safe annotation is not yet sufficient to ensure that the rest of 
> the system is in a valid state.

Please elaborate.

If @safe has a bug, it needs solving.

> Fail fast, and design the complete architecture with redundant HA 
> instance can take the (or a sub-set of the) load until the system can 
> regain its redundant operating condition.That is exactly what we do with 
> routers.

While all of those is within my recommendations generally, it does not 
cover this particular scenario.

This is far too common of an issue, and within business logic which will 
commonly be found inside a coroutine (including Fiber), it should not be 
bringing down the entire process.

ASP.net thanks to .net offers this guarantee for a reason.