Sers
Ich bastel mir gerade eine Klasse welche über set_error_handler und set_exception_handler eine standardmäßige Fehlerbehandlung und Debugfunktionen liefern soll (z.B. kontrollierte Ausgabe von Notices und Warnings anstatt am Seitenanfang etc.) sodas man in einem produktiven System das error_reporting anschalten kann ohne gleich alles zu zerstören.
Die Klasse steht, doch bevor ich nun weitermache bin ich am überlegen wie ich Fehlertypen, Fehlermeldungen und Fehlercodes am gescheitesten organisiere.
Dazu hab ich im Netz leider nicht viel finden können deswegen frage ich hier.
Zunächst gilt es ja Fehler in Typen zu klassifizieren.
Notice - Fehler die den Programmablauf nicht beeinträchtigen aber ggf. zu unerwünschten Resultaten führne können
Warning - Fehler welche eine Funktion/Methode zum Abbruch zwingen, Programm/Script kann weiter ausgeführt werden
Exception - Fehler welche das Programm/Script zum Abbruch zwingen wenn sie nicht behandelt werden können
Error - Fehler die nicht behandelbar sind und das Programm/Script stoppen
Kann man das als Klassifizierung so stehen lassen?
Weiter geht es mit der Organisation von Fehlercodes und -meldungen.
Die Fehlermeldungen direkt in den Code zu schreiben halte ich generell für eine schlechte Idee da sie dann schlecht wartbar/korrigierbar sind. Also Dinge a la:
Ich habe bloß keine Idee wie ich das zentral gut verwalten kann, sodas man im Code dennoch erkennt um welchen Fehler es sich handelt.
Ich suche also etwas a la:
Die Liste an Konstanten wäre bloß auf die Dauer ziemlich lang. Das gleiche gilt für Fehlercodes. Fakt ist aber das die Meldungen ja eh irgendwo niedergeschrieben werden müssen. Nur wie und wo?
Davon abgesehen sollte ja auch irgendwo aufgenommen werden um welche Komponente es sich handelt (System, View, Database, Registry, Modul etc.) die den Fehler ausgelöst hat.
Wie organisiert ihr sowas? Nach welchen Konzepten geht ihr da vor oder habt ggf. Lektüre für mich die gängige Konzepte erleutert?
Wie gesagt, meine Googlesuche war nicht wirklich aufschlussreich deswegen frage ich euch (ich weise darauf hin weil ich die Forumsrichtlinien zu Inseraten, Ideen, Meinungsumfragen kenne ).
Ich bastel mir gerade eine Klasse welche über set_error_handler und set_exception_handler eine standardmäßige Fehlerbehandlung und Debugfunktionen liefern soll (z.B. kontrollierte Ausgabe von Notices und Warnings anstatt am Seitenanfang etc.) sodas man in einem produktiven System das error_reporting anschalten kann ohne gleich alles zu zerstören.
Die Klasse steht, doch bevor ich nun weitermache bin ich am überlegen wie ich Fehlertypen, Fehlermeldungen und Fehlercodes am gescheitesten organisiere.
Dazu hab ich im Netz leider nicht viel finden können deswegen frage ich hier.
Zunächst gilt es ja Fehler in Typen zu klassifizieren.
Notice - Fehler die den Programmablauf nicht beeinträchtigen aber ggf. zu unerwünschten Resultaten führne können
Warning - Fehler welche eine Funktion/Methode zum Abbruch zwingen, Programm/Script kann weiter ausgeführt werden
Exception - Fehler welche das Programm/Script zum Abbruch zwingen wenn sie nicht behandelt werden können
Error - Fehler die nicht behandelbar sind und das Programm/Script stoppen
Kann man das als Klassifizierung so stehen lassen?
Weiter geht es mit der Organisation von Fehlercodes und -meldungen.
Die Fehlermeldungen direkt in den Code zu schreiben halte ich generell für eine schlechte Idee da sie dann schlecht wartbar/korrigierbar sind. Also Dinge a la:
PHP-Code:
trigger_error('shit happens!');
Ich suche also etwas a la:
PHP-Code:
define('SHIT_ERROR', 'shit happens!');
trigger_error(SHIT_ERROR);
Davon abgesehen sollte ja auch irgendwo aufgenommen werden um welche Komponente es sich handelt (System, View, Database, Registry, Modul etc.) die den Fehler ausgelöst hat.
Wie organisiert ihr sowas? Nach welchen Konzepten geht ihr da vor oder habt ggf. Lektüre für mich die gängige Konzepte erleutert?
Wie gesagt, meine Googlesuche war nicht wirklich aufschlussreich deswegen frage ich euch (ich weise darauf hin weil ich die Forumsrichtlinien zu Inseraten, Ideen, Meinungsumfragen kenne ).
Kommentar