[RFC] Throwing an exception with null pointers

[Derek Fawcus]

On Monday, 14 April 2025 at 16:12:35 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> 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.

I'd have to suggest you're chasing something which can not be 
achieved.

It is always possible for the program to get in to a partial, or 
fully, unrecoverable state, where some portion of the system is 
inoperative, or operating incorrectly.

The only way to recover in that case is to restart the program. 
The reason the program can not recover is that there is a bug, 
where some portion is able to drive in to an unanticipated area, 
and there is not the correct logic to recover as the author did 
not think of that scenario.


I recently wrote a highly concurrent program in Go.  This was in 
CSP style, taking care only only access slices and maps from one 
goroutine, and not accidentally capturing free variables in 
lambda.  So this manually covered the "safety" escapes which the 
Rust folks like to point to in Go.  The "safety" provided being 
greater than D currently offers.

Also nil pointers are present in Go, and will usually crash the 
complete program.  One is able to catch panics if one desires, so 
being similar to your exception case.

There were many goroutines, and a bunch dynamically started and 
stopped which ran "business logic".

Despite that it was possible (due to some bugs of mine) to get 
the system state where things could not recover, or for some 
cases took 30 mins to recover.  A flaw could be detected (via 
outside behaviour), and could be reasoned through by analysing 
the log files.

However for the error which did not clear after 30 mins, there 
was no way for the system to come back in to full operational 
state without the program being restarted.

A similar situation would be achievable in a Rust program.

In trying to handle and recover from such things, you're up 
against a variant of Gödel's incompleteness theorem, and anyone 
offering a language which "solves" that is IMHO selling snake oil.