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

[Walter Bright]

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.


> 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.


> 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.