Reply

Eclipse: Add Debug Statements to Code You Don't Own

At 10:24 PM on Jul 25, 2005, R.J. Lorimer wrote:

Okay, recently I posted on my frustration when working with certain libraries that are less than friendly to debuggers and extenders (*cough* javax.swing.text *cough*). One of the things I found that was really helpful in those scenarios was using System.identityHashCode() to give me a quick ID for an object programmatically that I could print out to the console to track an object instance (see General: When Debugging Get a Unique Identifier For Any Object ).

One of the tricky aspects of this, however, is when dealing with a lot of code that you don't own, you can't easily go changing it to add print statements to debug. Sure, you can still debug that code with breakpoints, but if the code in question is complex (like my favorite pain-to-debug example: SAX parsers) breakpoints are sometimes not the right solution. Besides, some code (such as UI event code) may need to have errors reproduced without affecting the execution (such as typing 3 characters, right mouse clicking, and hitting tab all without losing focus to reproduce a null pointer exception). In those cases, it would be nice to get in there, and throw some print statements in to see when code is hit (and potentially to print out any variable values at the time of the breakpoint). This can be done by 'cheating the system' in Eclipse a little bit, and using conditional breakpoints.

Conditional breakpoints are a handy feature in Eclipse that allow you to supply a condition contextually relative to the code being executed so that the breakpoint only stops when that condition is met. They can be really useful, and in a lot of cases they can make debugging a lot less tedious. They don't really help with what I am describing here exactly (at least not directly), but it is important to understand them. To create a conditional breakpoint for this code:

public void someMethod(String argument) {
 String a = getSomeValue();
 String b = getSomeOtherValue(); // conditional breakpoint on this line
}

... you add the breakpoint in your editor by either right clicking and adding it, or double clicking in the breakpoint gutter. Once installed, right click, select Properties for the breakpoint, and then enable a condition:

This breakpoint would then stop for the case when a, b, and argument are all equal. What we are wanting, however, has nothing to do with conditional breakpoints. We just want to add some print statements into a method we can change. We can use conditional breakpoints, however, to add arbitrary code during debugging. So, for instance:

By returning false, we ensure that the breakpoint won't actually stop, but instead when Eclipse is attempting to evaluate the breakpoint, it will unwittingly execute these lines of code, and continue on as if the breakpoint didn't exist.

Note one caveat - if you are already in a debugging session and step into the line, these lines won't be executed because Eclipse doesn't need to check the breakpoint condition since the thread is already suspended.

Give it a shot!

Until next time,

R.J. Lorimer
Contributing Editor - rj -at- javalobby.org
Author              - http://www.coffee-bytes.com
Software Consultant - http://www.crosslogic.com