nicht angemeldet
Tach!
Beim Debuggen geht es hauptsächlich darum, dass man zu den bereits entdeckten Fehlern deren Ursache ermittelt. Es gibt ja nicht nur Fehler, die eine Meldung generieren, sondern auch ungewünschtes Verhalten aufgrund von logischen Fehlern im Programm. Dazu muss man in Variableninhalte schauen,
Richtig. Einen Dump erzeugen und ab damit in den Browser. Damit man das gleich (und auch hier wieder: im Sinne von schnell) an Ort und Stelle abklären kann.
Einen Dump zu erzeugen ist ein unnötiger Zwischenschritt, der außerdem nur einen Stand zu einem bestimmten Moment abbilden kann. Damit Schleifendurchläufe zu untersuchen, oder allgemein wie sich Werte im Verlaufe des Codes ändern, ist mit vielen Dumps wesentlich umständlicher, als einen Breakpoint setzen zu können und dann schrittweise weiterzulaufen oder zum nächsten Breakpoint springen zu können und dabei jeweils life und in Farbe die Variableninhalte anschauen zu können. Sogar ändern kann man die Inhalte, um sofort sehen zu können, wie sich die Sache mit einem anderen Wert verhält.
Logisch daß man seine Dumps nicht dauerhaft erzeugt sondern nur während der Entwicklung.
Warum überhaupt, wenn man mit einem Debugger durch den Code gehen kann? Dumps können eher ihre Eigenschaften ausspielen, wenn man grad nicht mit der Entwicklungsumgebung zugange ist. Beispielsweise, wenn ein Fehler bei einem Anwender auftritt, kann ein Dump Informationen liefern, weil man schlecht auf der Anwendermaschine interaktiv debuggen kann. Nachteilig ist weiterhin, dass es nur ein Stand ist und man nicht unbedingt sieht, wie sich die Dinge entwickelt haben, die zu dem Stand führten.
Keine der bisher genannten Maßnahmen kann als allein seeligmachend angesehen werden.
Nö. Aber mit try/catch kommt man halt am Weitesten und in Sachen Qualitätssicherung am schnellsten zum Ziel.
Oder auch gar nicht, bei asynchronem Code.
dedlfix.