[RFC] Throwing an exception with null pointers
Richard (Rikki) Andrew Cattermole
richard at cattermole.co.nz
Mon Apr 14 21:36:42 UTC 2025
On 15/04/2025 9:28 AM, Richard (Rikki) Andrew Cattermole wrote:
> On 15/04/2025 8:53 AM, Derek Fawcus wrote:
>> 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.
>
> In my original post I proposed a three tier solution.
>
> The read barriers are secondary to the language guarantees via type
> state analysis.
>
> You need them for when using a fast DFA engine, that doesn't do full
> control flow graph analysis and ignores a variable when it cannot
> analyze it.
>
> But if you are ok with having a bit of pain in terms of what can be
> modeled and can accept a bit of slowness, you won't need the read barriers.
>
> Unfortunately not everyone will accept the slower DFA therefore it can't
> be on by default. I know this as it copies a couple of the perceived
> negative traits of DIP1000.
>
> So yes we can solve this, but MT could still mess it up, hence the last
> option in the three solution; signals killing the process.
I should mention, like the assert handler you would have the ability to
configure the read barrier to do whatever you want at runtime.
So if you prefer it to kill the process you can.
As to what the default would be? Idk.
The benefit of having it is that we can likely have a stack trace, where
there might not be one otherwise.
More information about the Digitalmars-d
mailing list