Walter Bright wrote:
Denis Koroskin wrote:
On Sun, 27 Sep 2009 01:49:45 +0400, Walter Bright
<[email protected]> 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
