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

[TS]

Hello,

Hallo,

Also als erstes Netzwerkkonsole im Browser öffnen

Nein. Das Erste ist die Fehlerbehandlung im Programm selbst.

ich hätte nicht gedacht, dass wir mal so einer Meinung sein könnten.
Aber ja: Erst mal die offensichtlichen Symptome betrachten. Und dann davon die Auswahl der Werkzeuge und Verfahren abhängig machen.

Merke: Man muss nicht gleich eine MRT machen, wenn der Patient deutlich sichtbar nur eine Schnittwunde hat.

Irgendwo muss die Fehlermeldung ja aufschlagen.

Bei einem ursprünglich laufenden Programmkonglomerat sollte der Userscreen die Fehlermeldung schließlich nicht anzeigen. Der sollte leer bleiben, oder bestenfalls einen Link mit "tut uns leid" zu einer übergeordneten Seite anzeigen.

Also nochmal von vorne:
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.

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.

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.

Hier ist jetzt die Chance, über [1] zu diskutieren. Das läge mir am Herzen!
Und schließlich sollte auch ein Server nicht lügen, sondern einen passenden Statuscode senden.

Wie sollte man vorgehen?
Das totale Abschalten und Ignorieren von Fehlermeldungen kann es doch nicht sein!?

Glück Auf
Tom vom Berg