Heute geht es um einen Bereich von Eclipse, den man eigentlich nur ungern sieht, da man ihn meistens nur bei Problemen braucht: den Debugger. Ich kann mir vorstellen, dass dies auch der Grund ist, weshalb viele den Debugger nur rudimentär beherrschen (Breakpoint setzen, Step-Into und Step-Over) und sich die Zeit nicht nehmen, die vielen Features genauer anzusehen. Dabei würde das schlussendlich auch Zeit sparen und man kann sich besser auf den Fehler konzentrieren.

Im nachfolgenden werde ich auf die verschiedenen Views und Funktionen die ich kenne kurz eingehen und ein paar Tipps geben. Ach ja, ich hab mir mal das “Textile Plug-in”:http://www.textism.com/tools/textile/ installiert und werde in Zukunft auch etwas mehr Formatierungen in den Text bringen

h3. Navigation im Debugger

Die Grundlegenden Kommandos für Debuggen sind wohl Step-Into (die nächste Subroutine), Step-Over (das aktuelle Statement) und Step-Return (aus der Subroutine). Was aber, wenn wir in einen ganz bestimmten Aufruf in einer Reihe verschachtelter Aufrufe steppen wollen?

if(!(findSelectedCall(config.getPos()) && findTargetClass(config.getTargetClassFinder()) && findMethodDefinition()))
 

Nehmen wir an, wir wollen nach findTargetClass steppen. Wir könnten einfach mit einigen Step-Into und Step-Return ans Ziel kommen, einen Break-Point in findTargetClass setzen *oder* wir markieren findTargetClass und steppen mit Ctrl+F5 direkt hinein. Zeit und Nerven gespart :-) .

Was ist, wenn wir mal zu weit gesteppt sind, aber immer noch in derselben Methode sind? Dafür gibts *Drop To Frame*:
drop_to_frame.png
Entweder im oberen Bereich der Debug-View oder im Kontextmenus des jeweiligen Stackframes.

h3. Breakpoints

Mit Breakpoints markieren wir die Stellen, an der der Debugger anhalten soll. Es gibt aber mehrere Arten von Breakpoints, wie Exception Breakpoints oder Conditional Breakpoints. Exception Breakpoints lassen sich über das _Run -> Add Java Exception Breakpoint…_ konfigurieren und halten dann den Debugger an sobald eine Exception des konfigurierten Typs eintritt. Sehr praktisch für Null Pointer Exception, da man dem Stacktrace nicht wirklich ansieht, was denn genau null war.

Conditional Breakpoints: Über das Kontext-Menu eines gesetzten Breakpoints lassen sich verschieden Properties setzen, zum einen den Hit-Count, welcher den Debugger nur stoppt, wenn der Breakpoint “Hit”-Mal erreicht wird, und zum anderen die genannten Conditions. Hier sehen wir ein Beispiel, bei dem der Breakpoint nur eintritt, falls der Parameter _test_ ist:

cond_breakpoint.png

h3. Detail Formatter

Die Variables-View in Eclipse ist ziemlich praktisch um einen Blick auf den Zustand des Programms zu werfen. Im unteren Teil gibt es eine kleine Textbox, welche Informationen (toString()) zum angewählten Objekt anzeigt. Das sieht dann beispielsweise so aus:

details_formatter_before.png

Sehr hilfreich sieht das aber nicht aus. Aber natürlich lässt sich das auch ändern: Rechtsklick auf den Listeneintrag -> _New Detail Formatter_ und im Fenster lässt sich dann Code eingeben, der im Kontext des Objekts evaluiert wird:

details_formatter_after.png

h3. Display View, Resultate inspizieren

Manchmal hat man, wie im Beispiel weiter oben, verschachtelte Aufrufe und man würde gerne das Resultat eines Aufrufs sehen. Anstatt den Code zu editieren und lokale Variablen zu erstellen, kann man den Ausdruck einfach mit der Maus markieren (Achtung, alle Klammern einbeziehen) und Ctrl-Shift-D drücken. Wenn man danach die gleiche Tastenkombination nochmals drückt, wandert die Selektion in die Display View und man kann den Code noch editieren und weiter evaluieren lassen.

So, das wars soweit, ich hoffe ihr konntet was lernen! Das nächste Thema wird wohl über Plug-Ins sein, die eigentlich jeder zum JDT installieren sollte.