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.
angenommen ich habe ein kompliziertes Programm und ich weiß, dass eine Variable x irgendwann einen
falschen Wert annimmt, wie beispielsweise x > 100. Nur weiß ich nicht, wo im Programm der Fehler vorliegt.
Wie kann man das in Netbeans herausfinden ? Mit Conditional - Breakpoints würde ich da nicht weiterkommen
(glaube ich), da man dort an einen Punkt im Programm gebunden ist.
Ich bräuchte also eine Variablen - Überwachung, die dann wie der Debugger "anspringt", wenn der kritische
Wert erreicht wurde.
Abgesehen von den Möglichkeiten des Debuggers könntest Du, wenn Du das Programm (temporär) verändern kannst, die Variable kapseln und im Zuweisungscode (setter) einen if-Zweig einbauen, der im gewünschten Fall durchlaufen wird.
Ich benutze dies oft, wenn ich umfangreiche Programmteile durchlaufen muss, um in die zu debuggende Situaion zu kommen.
TDD wäre zwar sauberer, aber manchmal ist der Aufwand dafür ziemlich hoch.
Also das hört sich genau nach conditional breakpoint an. Also an der Stelle, an der das geprüft werden soll, einen conditional breakpoint setzen. Dann im Debugger durchlaufen und wenn die Bedingung wahr ist, dann unterbricht der Debugger an der Stelle und Du kannst schauen, was Sache ist und so.
One of the most important developer activities is debugging. In my college days, we were forced to use simple text editors for our software development, so I...
@kneitzel: Angenommen, ich weiß nicht, an welcher Stelle im Code die Variable den kritischen Bereich erreichen könnte, wie überprüfe ich das ? Soweit ich weiß, sind die Conditional - Breakpoints immer an eine Stelle gebunden.
Ich glaube die Herangehensweise von Barista scheint die passende zu sein. Schade, dass es in Netbeans kein eingebautes Tool gibt, mit dem man das ganze eleganter lösen könnte.
Mehrere Breakpoints, ggf. per Debugger schrittweise durchgehen, Watch hinzufügen. Wenn Du einen Setter verwendest, ist es natürlich viel einfacher: dort einen Conditional Breakpoint setzen, den Callstack anschauen. Aber mal ernsthaft: was bitte ist das für Code, bei dem man solche Probleme mit dem Debuggen bekommt?
Ich bin noch nicht allzu erfahren, wenn es um Debugging und Fehlersuche geht, daher wäre dieses Variablen - Monitoring ganz gut gewesen. Mittlerweile habe ich aber verstanden, dass es eine gute Idee ist, bei den Set - Methoden anzusetzen.
Bei mir hat es eine Komponente gegeben, welche sich bei einem Mausklick vergrößert hat, ohne dass ich es wollte. Nur war es recht unübersichtlich, über die registrierten Action - Listener die dementsprechende Stelle herauszufinden. Aber nun weiß ich ja, dass man am besten bei den Set - Methoden ansetzen sollte. Wahrscheinlich war ich von der Komplexität zu verwirrt, um die einfache Herangehensweise zu erkennen.
Dann weißt du ja jetzt, warum man Zugriffe auf Variablen kapselt. Unter anderem genau deswegen.
Du kannst, wenn ein Breakpoint angesprungen wird, dir vom Debugger auch die Aufrufhierarchie ausgeben lassen. Dann kannst du sehen, von wem die Variable vorher geändert wurde.
Du kannst aber auch, wenn du weißt wo das Mausklickevent ist, einfach dort beginnen und dich Schritt für Schritt durch das Programm danach langhangeln. Du kannst zeilenweise weitergehen, du kannst aber auch schauen was in einer Zeile passiert und z.B. einen darunterleigenden Funktionsaufruf zeilenweise durchgehen.
