CodeGuide At Work
As the producers of an IDE that includes omniscient debugging facilities, naturally we use back-in-time debugging daily during development. CodeGuide works a bit differently than ODB in that it marries conventional debugging with back-in-time facilities. Thus, the developer can use conventional breakpoints when he wants to and go back in time when necessary. Once a breakpoint is set, CodeGuide instructs the debugged application to log execution details in the method containing the breakpoint and "related" methods. The rest of the application is not affected and can continue to run at full speed. If the bug is easy to fix, the developer can HotSwap his changes into the VM and test them without the need to restart the application.
Bugs in Java applications often manifest themselves in uncaught exceptions. The dreaded NullPointerException is probably the most common example.
Now, once a NullPointerException is thrown because the return value of a function is null, you usually have no clue why this function returned null. For example, I recently had to find a bug in some code that uses a cache to hold some per-file data. With omniscient debugging in CodeGuide, I just had to set a breakpoint on the main exception handler of this thread, and then I stepped backwards to the cause of the exception.
The code in which the NullPointerException was thrown looked like this:
class Processor {
private Cache cache;
public String process(File file) {
// ...
Data data = cache.getData(file);
// ...
return data.getStringRepresentation();
// <- NPE thrown
}
}
It was clear that the Cache.getData() method was at fault for returning null. But how could that happen? The Cache.getData() method was not supposed to ever return null. It was supposed to return dummy data instead:
class Cache {
private Map<File, Data> cachedFiles = new HashMap<File, Data>();
private Data getData(File file) {
if (!cachedFiles.containsKey(file))
return new DummyData();
return cachedFiles.get(file);
}
}
Stepping back into the Cache.getData() method revealed that the cachedFiles.get(file) returned null, even though cachedFiles.containsKey(file) returned True. A peculiarity of HashMap is that it allows storing null values, in contrast to Hashtable, which does not. Thus, changing the code to not use HashMap.containsKey() fixed the problem:
private Data getData(File file) {
Data data = cachedFiles.get(file);
if (data == null)
return new DummyData();
else
return data;
}
Could I have found this bug without omniscient debugging? Certainly. But it would have taken much, much longer and several debugging sessions with breakpoints in different locations to get to the root of this.
— Hans Kratz
http://www.omnicore.com/
