Summary: if an object's toString method returns null, when you step through code in the debugger, the object will be treated as null. So code behavior in the debugger is not the same as without the debugger. drjava-20100913-r5387 on MacOSX
Details:
Put the following code into DrJava:
public class Exp {
public int x = 17;
public String toString () { return null;}
public static void main (String [] args) {
Exp e = new Exp();
System.out.println(e.x);
}
}
Run it in the debugger. Output: 17, as expected.
Now put a breakpoint on the System.out.println(e.x) line. Run it in the debugger again. Hit the breakpoint. Hit "resume." Program crashes with a null pointer exception. Why? Because e.toString is null and somehow the debugger cares about this fact.
Not only does the debugger think your code should crash, but it also traces the code incorrectly: if you replace System.out.println(e.x); with
if (e==null) <some code>
then <some code> will get executed if you step through it in the debugger, but NOT otherwise. Again, the debugger thinks e is null because e.toString() is null.