[RFC] Throwing an exception with null pointers

[Paolo Invernizzi]

On Tuesday, 15 April 2025 at 07:23:14 UTC, Alexandru Ermicioi 
wrote:
> On Tuesday, 15 April 2025 at 02:48:42 UTC, Steven Schveighoffer 
> wrote:
>> On Monday, 14 April 2025 at 15:42:07 UTC, 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.
>>
>> This is the exact problem. The solution proposed here just 
>> doesn't understand what the actual problem is. Null 
>> dereferences, and index out-of-bounds are *programming 
>> errors*. You need to fix them in the program, not recover and 
>> hope for the best.
>
> This simply is not manageable. Sometimes it is better to have 
> semi operating systems rather ones that don't work at all 
> because a minor thing in a tertiary module causes npe, while a 
> fix is in progress.

Au contraire!

That's exactly why today we have:

- kernels (or microkernels!)
- processes living in userland
- threads living in processes
- coroutine (or similar stuff, whatever variant and name they 
take) living on thread
- and least but not last VM, plenty of them.

I don't see a real use case for trying to recover a process from 
UB at all: go down the list and choose another layer.

/P