Null references redux

[Jeremie Pelletier]

Walter Bright wrote:
> Denis Koroskin wrote:
>> On Sun, 27 Sep 2009 01:49:45 +0400, Walter Bright 
>> <newshound1 at digitalmars.com> wrote:
>>
>>> The problem with non-nullable references is what do they default to? 
>>> Some "nan" object? When you use a "nan" object, what should it do? 
>>> Throw an exception?
>>>
>>
>> Oh, my! You don't even know what a non-null default is!
>>
>> There is a Null Object pattern 
>> (http://en.wikipedia.org/wiki/Null_Object_pattern) - I guess that's 
>> what you are talking about, when you mean "nan object" - but it has 
>> little to do with non-null references.
> 
> It's the black hole object. It prevents you from getting a seg fault, 
> but I see no rationale for expecting that an unexpected null object 
> always returning "I succeeded" means your program will operate correctly.
> 
> The white hole object, of course, always throws an exception when it is 
> accessed. At least you know something went wrong - but you already have 
> that with null.
> 
> 
>> With non-null references, you don't have "wrong values", that throw an 
>> exception upon use (although it's clearly possible), you get a correct 
>> value.
> 
> You're not getting a correct value, you're getting another default 
> value. If the logic of your program is expecting a prime number > 8, and 
> the null object returns 0, now what?
> 
>> If an object may or may not have a valid value, you mark it as 
>> nullable. All the difference is that it's a non-default behavior, 
>> that's it. And a user is now warned, that an object may be not 
>> initialized.
> 
> He isn't warned, that's just the problem. The null object happily says 
> "I succeeded" for all input and returns more default values and null 
> objects.
> 
> What happens if the output of your program then becomes a null object? 
> How are you going to go about tracing that back to its source? That's a 
> lot harder than working backwards from where a null exception originated.
> 
> I used to work at Boeing designing critical flight systems. Absolutely 
> the WRONG failure mode is to pretend nothing went wrong and happily 
> return default values and show lovely green lights on the instrument 
> panel. The right thing is to immediately inform the pilot that something 
> went wrong and INSTANTLY SHUT THE BAD SYSTEM DOWN before it does 
> something really, really bad, because now it is in an unknown state. The 
> pilot then follows the procedure he's trained to, such as engage the 
> backup.
> 
> A null pointer exception fits right in with that philosophy.
> 
> You could think of null exceptions like pain - sure it's unpleasant, but 
> people who feel no pain constantly injure themselves and don't live very 
> long. When I went to the dentist as a kid for the first time, he shot my 
> cheek full of novacaine. After the dental work, I went back to school. I 
> found to my amusement that if I chewed on my cheek, it didn't hurt.
> 
> Boy was I sorry about that later <g>.

Haha that's a nice analogy, I myself was just unable to speak. I guess 
that's what you call undefined behavior!

That's exactly the point with nonnull references, they turn access 
violations or segfaults into undefined behavior, or worse into generic 
behavior that's much harder to track to its source.

I think nonnull references are a nice concept for languages that have a 
higher level than D. If I expect references to never be null I just 
don't check for null before using them, and let the code crash which 
gives me a nice crash window with a backtrace in my runtime.

Jeremie