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

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Jan 17 13:10:44 PST 2014


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. The callback could've been invoked from any
number of places (usually callbacks are factored into generic functions
so that you don't have to deal with writing 500 callbacks just to handle
the response to each event type), so you have to deduce which of the n
number of possibilities may have caused it. Usually, that only leads to
finding that the previous event handler was only passing things along,
so you have to go back yet another step in the chain.

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.

If you're very very lucky, you may have a log of events that help narrow
k to a sufficiently small number that allows quick deduction of where
the problem is. Often, though, all you have is a stack trace from an
inaccessible customer production server, and you'll have to explore n^k
possibilities before you can find the problem. (Even a stack trace
should already be counted as lucky; I've had to fix *race conditions*
with no stack trace and only indirect evidence that a daemon died and
got restarted by init. It took months before we could even reproduce the
problem -- it was highly dependent on precise network timing -- much
less guess at what went wrong.)

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.


T

-- 
Кто везде - тот нигде.


More information about the Digitalmars-d mailing list