1. Your Situation
You find yourself debugging a Java app with Eclipse and you’re stepping through the code in the Debug perspective. You have the Variables view open and for most of the selected types you can see a reasonable toString() output below the variables list.
However, many types don’t have a type specific implementation of toString(). E.g., consider an array of objects. There’s no toString() on arrays. That’s why the variables view prints you some meaningless default text with a hashcode for such variables.
But did you know that you can change that by defining a custom toString() implementation that’s used by the variables view at runtime? Let me introduce you to the concept of Detail Formatters and learn about the Display view along the way, too.
2. Preparing a custom type evaluation
Lets start at a breakpoint in some arbitrary code as shown in the following screenshot. The debugger stopped within a for-loop that iterates over a collection of CellBindDesc elements. In the Variables view the variable desc is selected to see what’s inside. Unfortunately, the class CellBindDesc didn’t override toString(). That’s why the default gibberish is printed below the variables list .
You do not need to know all the details about the CellBindDesc. It’s enough to know that it’s a description of mapping a model element’s field to an uiElement, e.g. a String property to a Text field.
To find a specific field of a model element the CellBindDesc holds an array of model element properties that’s similar to a tree path. The first element is a reference to a property of the model root element that’s stored in the model field of CellBindDesc. The other elements are references to properties of the model tree.
So, what I actually want to see below the variables list is not the gibberish, but at least the path to the model property and a hint to which uiElement it is bound. Sounds like some StringBuilder code, right? To create and test this code on the fly you should open the Display view . Imagine this view as being a container of code statements that are inlined at the position of the current debug step. In case of the screenshot above that would be line 170.
But the code is not really inlined. Instead you can use the Inspect command to execute the selected statements at that debug step. You can run that command with [Ctrl]+[Shift]+[I].
As you can see in the screenshot all lines are selected and the last statement even is a return statement that concatenates stuff to a String. Running [Ctrl]+[Shift]+[I] on that selection will show the familiar Inspect popup containing a String node with the return value if you did it right.
As you can see in this example, the Display view is very powerful. It’s so important to me, that I always open it when debugging. By the way, code completion does work there, too.
3. Edit the Detail Formatter
Now, with the snippet being tested in the Display view and the result being what one would actually like to see at it’s time to configure the Detail Formatter. Open the context menu on the variable for which you wish to configure a Detail Formatter and select the Edit Detail Formatter… entry .
In the Edit Detail Formatter dialog paste the snippet from the Display view and make sure the Detail Formatter is enabled.
After closing the dialog you should see the detail formatted output of your selected variable. In case of my example I’m now able to see the type, the model path and the ui element of each CellBindDesc directly below the variables list.
As the Detail Formatter is used for every instance of the type on which it is defined I am now able to step through the list via [F8]. No more need to check each property of the variable desc until I know all the values I need to tell if something is wrong. Ain’t that a great time safer? I bet it is!
4. Happy Debugging
Things you should have learned:
- Always open the Display view when you’re in the Debug perspective and make use of it. You can even collect several statements there and select only the one(s) you need for inspection depending on your debug context.
- Write Detail Formatters for arrays and complex types to show more details in the Variables view. Detail Formatters do even override toString() implementations if there should be one!