nicht angemeldet
Tach!
Noch schneller kommt man zum Ziel wenn man, in einer Entwicklungsumgebung die der Produktivumgebung weitestgehend gleicht, die Fehler sofort sieht. Nur so ist die Wahrscheinlichkeit, eine fehlerfreie Anwendung in die Produktion zu stellen am größten.
"Noch schneller" ist hier aber nicht als "die bessere Methode" anzusehen, sondern als ergänzende Maßnahme. Dass man schneller sieht, dass etwas schiefläuft, ist erst der Anfang. Damit ist die Frage nach dem Warum noch lange nicht geklärt. Dafür kommen unter anderem die Debugger ins Spiel.
Im Falle des OP geht es darum, dass das Fehlverhalten bereits bekannt ist und nun Strategien zur Ursachenermittlung gefragt sind.
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, während man schrittweise durch den Code läuft. Sowas kann man nicht sinnvoll lösen, indem man von vornherein seinen Code mit Debug-Ausgabe vollstopft.
Keine der bisher genannten Maßnahmen kann als allein seeligmachend angesehen werden. Zu einem robusten Programm gehört sowohl Fehlverhalten zu erkennen, was meist Zustände in anderen Systemen betrifft, auf die man nicht direkt Einfluss hat (z.B. Datenbank grad nicht erreichbar), als auch Situationen im eigenen Code zu erkennen, die man nicht bedacht hat, und dazu Strategien zur Ursachenermittlung. Und auch fehlerreduzierende Maßnahmen gehören dazu, wie beispielsweise Test Driven Design.
dedlfix.