|
From: SourceForge.net <no...@so...> - 2011-12-06 03:34:07
|
Bugs item #3451960, was opened at 2011-12-05 19:34 Message generated for change (Tracker Item Submitted) made by reyzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=3451960&group_id=44253 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Debugger Group: 4: Serious Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leonid Reyzin (reyzin) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger steps through code incorrectly Initial Comment: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=3451960&group_id=44253 |