Fehlerbehandlung

[jonathan09]

Hallo zusammen!

Ich habe an Euch Profis ein paar Fragen zur praktischen Umsetzung von Fehlerbehandlungen.

Habe im Netz (und auf php.net) Informationen zu error_reporting und set_error_handler studiert, möchte aber vor allem ein paar Tipps von Euch zur Praxis erhalten.

Es können ja immer Fehler im Code auftreten; wie sollte damit umgegangen werden? Die Fehler bekomme ich als Programmierer ja nicht direkt mit, da sie meist bei Anwendern - und nicht bei mir - auftreten werden. Sollte der Anwender die Fehler ausgegeben bekommen oder stellt Ihr die Ausgabe mit
error_reporting(0);
komplett ab? Was ist in diesem Fall mit Fehlermeldungen aus MySQL Abfragen? Sollte das komplette Skript dann abgebrochen werden? Speichert Ihr Fehlermeldungen in Datenbanken / Textdateien?

Würde mich über ein paar Infos sehr freuen (gerne natürlich auch allgemeine Dinge, nach denen ich nicht direkt gefragt habe... )

Danke an alle und vG

 

[NetAktiv]

Sollte der Anwender die Fehler ausgegeben bekommen oder stellt Ihr die Ausgabe mit
error_reporting(0); komplett ab?

Na wenn du die Fehler abfängst und eine nette Meldung ausgibst, dann musst den Nutzer nicht mit kryptischen PHP/SQL Fehlern belästigen. Übel wäre allerdings, wenn er denkt, es hat alles geklappt :-) und du nur etwas in deine übervollen Protokolle schreibst, die du nur alle 4 Wochen auswertest.

 

[jonathan09]

Na wenn du die Fehler abfängst und eine nette Meldung ausgibst, dann musst den Nutzer nicht mit kryptischen PHP/SQL Fehlern belästigen. Übel wäre allerdings, wenn er denkt, es hat alles geklappt :-) und du nur etwas in deine übervollen Protokolle schreibst, die du nur alle 4 Wochen auswertest.

Wenn überhaupt... ;-)

Also alle Fehlermeldung abschalten und eine eigene Ausgabe erzeugen?

Was aber ist mit Fehlern, welche die Ausführung des Skriptes nicht beeinträchtigen? Diese sollte natürlich auch nicht berücksichtigt werden...

 

[jonathan09]

Habt ihr dazu noch eine Idee?

VG

 

[jonathan09]

Sind nur E_USER_ERROR Fehler, welche das Skript abbrechen lassen? Oder auch Warnungen, Notizen?

Ich möchte mir eine Fehlerbehandlung schreiben, welche den User bei Fehlern gar nicht informiert, außer es sind so gravierende, dass das Skript nicht mehr richtig funktioniert... Dazu zählen natürlich auch insbesondere Fehlermeldungen resultierend aus SQL Abfragen. Diese werden aber bei dem BSP-Skript auf der Seite PHP: set_error_handler - Manual mit default abgefangen. Habe es eben ausprobiert - fehlerhafte Datenbankeinträge...

VG

 

[NetAktiv]

Was aber ist mit Fehlern, welche die Ausführung des Skriptes nicht beeinträchtigen?

Gibt es so etwas? Ein Fehler beebndet doch normal das Script, es wird also nicht fertig ausgeführt und damit wird es doch beeinflusst.

 

[mermshaus]

Ein paar grundsätzliche Aussagen dazu:

1. Ein Nutzer sollte keine internen Fehlermeldungen zu sehen bekommen. „Intern“ meint die Standard-Meldungen, die PHP oder Komponenten wie Datenbank-Adapter generieren. Normale Nutzer können damit ohnehin nichts anfangen, Angreifern helfen diese Meldungen aber, Schwachstellen zu entdecken oder Informationen über das System zu gewinnen (zum Beispiel Tabellen- und Feldnamen einer Datenbank oder Pfade von Script-Dateien) Wenn schon etwas schief läuft, ist das das Letzte, was wir wollen.
2. Es ist nicht leicht, eine wasserdichte Fehlerbehandlung zu programmieren. Ich habe dafür gerade kein besonders gutes Beispiel, aber in einem Script können viele Dinge falsche Werte zurückgeben, die wahrscheinlich niemals darauf überprüft werden. Nehmen wir vielleicht mal eine Funktion wie file_get_contents. Wer prüft jede Rückgabe von file_get_contents auf !== false? Ich tue das nicht. Dabei steht in der Doku: „The function returns the read data or FALSE on failure.“ Ich wette, dass frei nach Gene Kranz die meisten Programmierer bei solchen Befehlen sagen: „Failure is not an option.“
3. Shit happens. Fehler passieren. Der am meisten vernachlässigte Bereich bei der Entwicklung von Software ist vermutlich die Qualitätssicherung. Das wird bei „Tante Ernas Blumenladen“ vielleicht niemals jemanden interessieren, aber fragt zum Beispiel Sony. Das „Problem“ ist, dass selten jemand Geld dafür ausgeben will, sein Programm oder seine Seite gegen Angriffe abzusichern, die vermutlich niemals auftreten werden. Dabei gibt es Programmierparadigmen, die von sich aus darauf ausgelegt sind, Fehler zu reduzieren. Das ist zum einen ganz simpel objektorientierte Programmierung (Objekte können einen gültigen, internen Zustand durchsetzen, assoziative Arrays können das nicht) und zum anderen etwa testgetriebene Entwicklung (TDD).
4. Selbst wenn Quellcode fehlerfrei ist, die Ausführungsumgebung muss es nicht sein. Eine Anwendung geht üblicherweise und notgedrungen von einem bestimmten Setup des Webservers oder der PHP-Installation aus. Eine passende Umgebung lässt sich zwar im Code durch gewisse Abfragen ansatzweise sicherstellen, aber alle Eventualitäten werden dadurch vermutlich nicht abgedeckt werden können. Beispielsweise kann eine Anwendung davon ausgehen, dass die mb_*-Befehle standardmäßig UTF-8 nutzen. Das muss aber in der Konfiguration nicht so eingestellt sein. Ein Aufruf von mb_internal_encoding wird dadurch praktisch zur Pflicht.

Zu konkreten Strategien zur Fehlerbehandlung schreibe ich vielleicht in einem weiteren Post noch mal was.

 

[Anusha]

Also ich sehr daran interessiert zu diesem Thema noch was von dir zu lesen ;)