nicht angemeldet
Tach!
Im Falle des OP geht es darum, dass das Fehlverhalten bereits bekannt ist und nun Strategien zur Ursachenermittlung gefragt sind.
try/catch und raise error. D.h., daß man auch Warnungen in den Status einer Exception erhebt damit man das gleich mitbekommt. Damit dürfte Auch Dir klar sein, was ich im Sinne von "schneller zum Ziel" meine.
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.
Sowas kann man nicht sinnvoll lösen, indem man von vornherein seinen Code mit Debug-Ausgabe vollstopft.
Logisch daß man seine Dumps nicht dauerhaft erzeugt sondern nur während der Entwicklung. Ich habe das oft genug erlebt, daß Code im Debugmodus ins Repos gecheckt und sogar deployed wurde. Wenn man da hingegen den ganzen Rahmen in einen try/catch Block setzt, lassen sich solche Peinlichkeiten vemeiden, wenn da jemand seine Debugausgabe stehen lässt wird das nämlich sofort bemerkt. Es gibt nichts Schlimmeres als Debug-Ausgaben ins Logfile zu schicken, i.d.R. haben das diejenigen die sowas machen, spätestens beim Ertönen der Feierabendglocke vergessen und können sich am nächsten Tag an nichts mehr erinnern.
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.
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),
Das ist der klassische Fall für Exceptions. Und das spricht eben auch dafür, sein ganzes FW in einen try/catch Block zu setzen, sowohl während der Entwicklung als auch für den produktiven Betrieb. D.h., daß zum Deploy der Code nicht mehr verändert werden muss.
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.
Wenn man das gesamte Errorhandling über Exceptions abwickelt, ist bei großem Wartungskomfort auch die Qualität gesichert. Es ist dann nur noch eine Frage in welcher Form eine Fehlermeldung ausgegeben werden soll. Liegts am Benutzer wird man dem natürlich nicht eine Meldung in text/plain vor die Nase setzen sondern das Formular mit der fehlerhaften Eingabe in rot.
Einen Entwickler auf die Zeile zu tracen wo er das API falsch verwendet, ist logischerweise auch kein Fall für den Endanwender. D.h., daß eine falsche Anwendung einer API seitens des Enwicklers sowieso in einem die enden muss damit sowas gar nicht erst rausgeht.
Und wie gesagt, damit komme ich zurück zu meiner ersten Wortmeldung hierzu. Ein FW stellt einen Rahmen den man auch im Code wiederfindet: In Form von genau 2 Zeilen, nämlich da wo dieser Rahmen beginnt und wo er endet. Alles was an Code erforderlich ist und ggf. hinzukommt, wird nicht etwa neu in diesen Rahmen geschrieben sondern der Rahmen definiert Schnittstellen die das Einbinden von Code klar definieren.
Spannt man einen try über diesen Rahmen, vermeidet man damit nicht nur redundanten Code bezüglich Fehlerbehandlung sondern schafft auch die Grundlage für einheitliche Verfahren hinsichtlich Qualitätssicherung und Eskalationsprozesse (SMS, Mail an Verteiler, Wallboard usw.). MfG