On 7/25/2011 9:20, Warp wrote:
>    But that's the problem: The buggy part of your code might not be in the
> call stack at all anymore at the time the null pointer exception (or whatever
> other symptom) happens.

Well, sure. I thought I had expressed it more clearly than that.

In the case that the broken code isn't the code in the call stack, you debug 
it the same way you'd debug code in C or C++ that wasn't doing undefined 
unsafe stuff - you'd figure out the infection that led to the error, figure 
out the defect that led to the infection, and correct the defect.[*]

For example, if the null came from an instance variable, you'd find the 
place the instance variable got initialized, breakpoint it, and see if it 
gets set. If not, figure out why not. If so, figure out where it gets set 
*again*, by breakpointing any assignment that sets it back to null. Etc.

The only difference in an unsafe language is you either need a debugger that 
can breakpoint not based on source code (i.e., that you can breakpoint based 
on writing to the memory via a wild pointer, which I imagine is most of them 
these days at least on normal desktop-class machines). It's harder to 
analyze because if you *can't* find the problem, you can't just say "find me 
every reference to this variable in the codebase."



[*] Those are apparently the technical terms.
"Error: Program gave wrong results."
"Infection: Program state that is not as it should be."
"Defect: Code that made the program state other than what it should be."

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message