Fehlerbehandlung, Logging, Userscreenmeldungen, HTTP-Status (plural)

[TS]

Hello,

Da bin ich dabei. Im Entwicklungsstadium darf das Programmkonglomerat, wie du es nennst, aber durchaus gesprächig sein.

Um herauszufinden, welche Ressource herumzickt, schaue ich zuerst in die (Netzwerk-)Konsole des Browsers, dann ins zugehörige Log, aus dem ich dann vielleicht die Fehlermeldung des OP herausfiltern konnte.

Gut. Und ich schaue mir, bevor ich die Superwaffe "Developer Tools" zücke, erstmal aus Client-Sicht an: Was bekomme ich überhaupt? Oft erkenne ich daraus schon, was das Problem ist, und muss gar nicht erst den Phaser benutzen.

Da es diejenige Diagnosemöglickeit ist, die ich an einem DT-Platz direkt vor mir habe, sehe ich das keinesfalls als das "MRT" der Fehlersuche an. Das wäre mMn, WireShark anzuschmeißen, o. ä.

Erst dann kann ich im zugehörigen Programmmodul rund um die benannte Zeile schauen, ob ich mich z. B. vertippt habe oder ob ein logischer Fehler vorliegt, der dann zu unterschiedlichem Laufzeitverhalten ("Blinkerfehler") führt.

Wir haben also unterschiedliche Indikatoren, verfolgen aber im Prinzip die gleiche Strategie. Ich versuche es mit den (aus meiner Sicht) einfachen Mitteln, du gehst gleich mit der MRT los, um den Vergleich nochmal aufzugreifen.

Der OP war der Ursache doch schon ziemlich nah gekommen, hat aber mMn keine sinnvolle Basisstrategie für die Anzeige/Behandlung/Unterdrückung/Logging [1] von Fehlern und für die Reihenfolge der Suchschritte, mit der man die Fehler dann finden kann.

Ja. Das ist vermutlich der geringen Erfahrung im Debugging geschuldet. Daraus würde ich aber nur demjenigen einen Vorwurf stricken, der das schon jahrelang oder sogar beruflich macht.

Hier ist jetzt die Chance, über [1] zu diskutieren. Das läge mir am Herzen!

Meinetwegen gern. Einen Ansatz habe ich schon von mir gegeben.

Nur bist Du bisher nicht darauf eingegangen, dass man immer alle möglichen Fehlermeldungen nutzen sollte und wie man das dann zweckmäßigerweise organisiert. Wer sich darüber nicht vor der Programmcodierung bereits Gedanken macht, hat den schlimmsten Fehler schon eingebaut, bevor er überhaupt die erste Zeile Code geschrieben hat.

Und schließlich sollte auch ein Server nicht lügen, sondern einen passenden Statuscode senden.

Auch dazu habe ich mich in eben diesem Beitrag schon geäußert.

Gut :-)

Das totale Abschalten und Ignorieren von Fehlermeldungen kann es doch nicht sein!?

Im Gegenteil. Während der Entwicklung sollte man alle nur denkbaren Quellen für Hinweise und Meldungen belauschen.

Man sollte immer alle möglichen Meldungen nutzen!
Die Frage ist nur, wo man sie auflaufen lässt.

Alle Programmierfehler (und damit auch die Notices) sollten zur Entwicklungszeit beseitigt werden. Behandelbare Laufzeitfehler sollten zur Laufzeit behandelt werden, ggf. mif Roundturn und Zwischenanweisungen an den User.

Nicht behandelbare Laufzeitfehler sollten logged werden und auch zeitnah angeschaut. Bei schweren Fehlern dann z.B. eMail an den Admin. Ggf. Zwangsstopp der Applikation einleiten (Generelle "zur Zeit außer Betrieb"-Meldung) für den Userscreen.

Zugriffsfehler (Auth) sollten in einem separaten Log auflaufen, dessen Format von fail2ban auswertbar ist.

Wer es sich angewöhnt, schon zur Entwicklungszeit Fehlermeldungen auf dem Userscreen zu vermeiden und dort konsequent nur Anweisungen an den User und was er eben sonst so sehen soll/will, unterzubringen, der hat später zur Laufzeit keinen Ärger mehr damit.

Glück Auf
Tom vom Berg