Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Eclipse, beim Debugger Objekte nach Wert durchsuchen
Sry es ist eigentlich eine Eclipse-Frage, aber da viele ja Eclipse zum Erlernen von Java nutzen fand ich ich es hier doch bei Basics passend.
[Anmerkung SlaterB: und doch verschoben ]
Ich versuche gerade in Eclipse mit der Java Excel API, Werte aus einem Excel Sheet zu lesen.
Ich wüsste gerne ob mein Methode den richtigen Sheet-Namen einliest, bzw in dem Sheet den richtigen String einliest.
Nun kann der mir im Debug-Modus ja meine Sheet-Variablen/Objekte anzeigen lassen, aber diese sind sehr groß (riesige Baumstruktur) und ich finde einfach meinen Wert nicht.
Nun die Frage ist: Wie kann ich diese Baumstruktur durchsuchen ohne alle von Hand zu öffnen. Mein Problem ist auch, dass ich gar nciht weis unter welcher Variable im Objekt mein String steht.
Das funktioniert so nicht, zumindest nicht mit dem Debugger. Normalerweise schreibt man sich dafür JUnit-Tests, welche man gegen die Klasse laufen lässt. In diesen (J)Unit-Tests werden solche Dinge geprüft.
bisschen billig, debuggen muss man doch täglich tausende Dinge, was unterscheidet diesen speziellen Fall von anderen bzw. was ist das Kriterium für JUnit?
- Debugger weg, jeder einzelne Prüfung gleich JUnit?
- wenn Debugger zu kompliziert, dann JUnit?
soweit ich es vom Hörensagen kenne gibt es in Debuggern die Möglichkeit kleine Fenster mit Code zu befüllen um etwas mehr als nur direkt Variablen anzuschauen,
für diese Suche dürfte das aber nicht reichen, ich empfehle auch normalen Code,
natürlich kein JUnit für eine einmalige Sache, einfach Code normal ablaufen lassen und mit System.out.println() den Programmzustand untersuchen
wenn du den inneren Aufbau von Objekten nicht kennst wird es schwierig, wobei du in Java vielleicht doch letztlich Methoden wie getSheetName() abfragen kannst, was im Debugger vielleicht nicht direkt ins Auge fällt, obwohl evtl. möglich,
anderenfalls mit aufwendigen Reflection-Monstern arbeiten, da kommt der Debugger durchaus auch wieder leicht in Frage,
der Reflection-Blick ist seine tägliches Brot, aber wenn es nun mal nicht genau eine passende Methode 'suche in internen Aufbau' gibt, wie ich vermute, dann zu unflexibel gegenüber normalen Code
soweit ich es vom Hörensagen kenne gibt es in Debuggern die Möglichkeit kleine Fenster mit Code zu befüllen um etwas mehr als nur direkt Variablen anzuschauen
Möglichkeit a) Windows > show view > other... da nach "Display" suchen. In diesem View kann man Code eintragen und präzise ausführen (Code markieren + auf das Lupensymbol klicken)
Möglichkeit b) im source eine code-zeile markieren -> rechtsklick -> Inspect (Strg+shift+i). Geht auch, dass man on-the-fly code in seine sourcecode datei einfügt (speichern ist nicht notwendig) und dann das inspect ausführt ... ist also das gleiche wie Möglichkeit a nur eben nicht in einer separaten view.
Kleiner Hinweis, auch wenn das in diesem Fall vielleicht nicht 100% passend ist. Es gibt auch die Möglichkeit Breakpoints mit einem Stückchen Code zu versehen. Einfach mal Rechtsklick auf den Breakpoint und "Breakpoint Properties" anklicken.
Ob jetzt JUnit oder nicht, ist relativ egal, aber ich persönlich sehe die Bedeutung von Tests wahrscheinlich etwas anders als du.
Für mich ist so eine Aufgabe auch prädestiniert dafür mit Tests ausgestattet zu werden. Denn eine Test-Suite hat letztlich einige Vorteile. Man hat einen bekannten Input, hat eine Erwartung an das Ergebnis und testet somit genau das Stückchen Code, das davon betroffen ist. Das kann man natürlich auch als "Wegwerf-Test" modellieren oder einfach per Debugging so lange anpassen, bis es klappt. Aber hat man mal einen Test geschrieben, dann kann der für alle Zeit laufen und sobald - aus welchem Grund auch immer - diese eine Codestelle ein falsches Ergebnis liefert, wirst du es merken, da die Test-Suite dir das sagt.
Es geht ja auch nicht darum, zu jedem Problem einen Test zu schreiben. Aber Methoden zu testen ist sicherlich keine schlechte Idee und so wie sich das hier ließt, hat der TO ja eine eigene Methode für dieses Problem.
]
