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.
