Non-null objects, the Null Object pattern, and T.init

[H. S. Teoh]

On Fri, Jan 17, 2014 at 01:29:53PM -0800, Walter Bright wrote:
> On 1/17/2014 1:10 PM, H. S. Teoh wrote:
> >On Fri, Jan 17, 2014 at 11:43:59AM -0800, Walter Bright wrote:
> >[...]
> >>I've almost never had a problem tracking down the cause of a null
> >>pointer. Usually just a few minutes with a debugger and getting a
> >>backtrace.
> >
> >I think this depends on the kind of code you write.
> >
> >In callback-heavy code, usually when you're multiplexing between many
> >simultaneous request/response chains, these kinds of problems are
> >very hard to track down.  You'll see the null pointer somewhere in
> >your callback's context structure, but no amount of backtrace will
> >help you go any further because they all end at the event dispatch
> >loop pretty shortly up the stack, which doesn't tell you where in the
> >chain of events the null came from.
> 
> What you do then is go back as far as practical, then put asserts in.

Of course, but that requires a few rounds of recompilation, repacking
the EEPROM image, installation on device, and repeating a user
interaction that possibly only randomly hits the bug. Hardly the work of
a few minutes.


> >When there are n possible ancestors for each step in the chain,
> >you're talking about n^k possible paths to investigate before you
> >find the ultimate culprit. A few minutes is not going to suffice,
> >even for moderate values of k.
> 
> Put asserts in, maybe a printf too. I do it all the time to track
> down problems. Memory corruption can be a difficult one to track
> down, but I've never had trouble tracking down a null pointer's
> source. They aren't any harder than any "I have a bad value in this
> field, I wonder who set it" problem.
> 
> I.e. it isn't special.

True.

But in many cases, the source of a bad value is easy to find because of
its uniqueness (hmm, why does variable x have a value of 24576? oh I
know, search for 24576 in the code). Nulls, though, can occur in many
places, and in D they are implicit. There's no easy way to search for
that.


> >Nipping the null at the bud (i.e., know where in the code it was
> >first set as null) is a real life-saver in these kinds of situations.
> 
> It's better for any bug to catch it at compile time.
[...]

Currently D doesn't allow catching nulls at compile-time.


T

-- 
Give me some fresh salted fish, please.