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.
