ErrorHandling-Objekt

[mod]

Hallo

ich arbeite derzeit an einem ErrorHandling-Objekt, quasi also Ersatz für die PHP eigene Fehlerbehandlungsroutine. Alle DB-Fehler, NOTICEs, WARNINGs, etc werden abgefangen, in einem Errorlog gesichert und es wird das PHP-Script vor Ausgabe des Templates gestoppt. Bis vor der Ausgabe des Templates (HTML-Codes) werden alle möglichen Meldungen abgefangen. Ist das gut so ?

Was soll ich dem User für eine Fehlermeldung präsentieren? Vorschläge? In bereits zu diesem Thema behandelten Threads wurde darauf hingewiesen keine System-Infos auszugeben, wegen Sicherheit!

Gruß mod

[Cheatah]

Hi,

Was soll ich dem User für eine Fehlermeldung präsentieren? Vorschläge?

ja, beispielsweise. Besser als Vorschläge wäre natürlich, dem User das zu liefern, was er als Ergebnis erwartet.

Bedenke, dass der User nichts für den Fehler kann. Der Entwickler hat etwas zu unternehmen, niemand sonst.

Cheatah

[Tom]

Hello,

Was soll ich dem User für eine Fehlermeldung präsentieren? Vorschläge?

ja, beispielsweise. Besser als Vorschläge wäre natürlich, dem User das zu liefern, was er als Ergebnis erwartet.

Bedenke, dass der User nichts für den Fehler kann. Der Entwickler hat etwas zu unternehmen, niemand sonst.

Nicht jeder "Fehler" ist ein Programmiererfehler. Manche "Fehler" sind auch ganz normale, erwartbare  Programmreaktionen. Da ist es dann nur ein Fehler, wenn der Programmierer nichts damit macht.

PHP unterstützt noch kein intelligentes Fehlermanagement, da es die eindeutigen Nummern der üblichen erwartbaren Fehler immer noch verschluckt, und stattdessen hardcoded Texte dafür ausspuckt, die aber leider bis heute nirgendwo verlässlich dokumentiert sind. Die muss man z.B. also erst mittels

iniset('track_errors', 1);

und Abfrage der Systemvariablen $php_errormsg mühevoll rückgewinnen und zurückentwickeln auf eine (eigene) Fehlernummer.

http://www.php.net/manual/en/reserved.variables.phperrormsg.php

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Cheatah]

Hi,

Bedenke, dass der User nichts für den Fehler kann. Der Entwickler hat etwas zu unternehmen, niemand sonst.
Nicht jeder "Fehler" ist ein Programmiererfehler. Manche "Fehler" sind auch ganz normale, erwartbare  Programmreaktionen. Da ist es dann nur ein Fehler, wenn der Programmierer nichts damit macht.

mit anderen Worten: Der Entwickler hat etwas zu unternehmen. Oder?

Cheatah

[Solemon]

Halllo

Bedenke, dass der User nichts für den Fehler kann. Der Entwickler hat etwas zu unternehmen, niemand sonst.
Nicht jeder "Fehler" ist ein Programmiererfehler. Manche "Fehler" sind auch ganz normale, erwartbare  Programmreaktionen. Da ist es dann nur ein Fehler, wenn der Programmierer nichts damit macht.

mit anderen Worten: Der Entwickler hat etwas zu unternehmen. Oder?

er meinte wohl: User?

Edit: wie jetzt gerade, eine Fehlermeldung wegen zuvielen zitierten Zeichen. Ho ho, und jetzt muss der USER was damit machen, nämlich nochmal das Formular abschicken. So einfach geht's!

[Tom]

Hello,

Bedenke, dass der User nichts für den Fehler kann. Der Entwickler hat etwas zu unternehmen, niemand sonst.

Nicht jeder "Fehler" ist ein Programmiererfehler. Manche "Fehler" sind auch ganz normale, erwartbare  Programmreaktionen. Da ist es dann nur ein Fehler, wenn der Programmierer nichts damit macht.

mit anderen Worten: Der Entwickler hat etwas zu unternehmen. Oder?

Jein. Denn der User kann durchaus verantwortlich sein für den Auslöser des Fehlers, der Entwickler muss dies aber abfangen. Der User kann also durchaus mitverantwortlich am Programmverhalten sein. Wäre ja noch schöner, wenn das schon vollständig vorherbestimmt wäre :-D

Zuerst hätten aber mal die Entwickler von PHP was zu unternehmen. Der Eingriff wäre auch gar nicht so tragisch, nur eine kleine Fleißarbeit...

Beseitigung der textuellen Fehlermeldungen. Erzeugen einer eineindeutigen Fehlernummer, die man dann wieder mittels Funktion in einen fehlertext umsetzen kann, wenn es denn notwendig erscheint. Aber eine sichere Größe wegzurationalisieren und gegen eine vage zu ersetzen, das ist nicht professionell!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Cheatah]

Hi,

mit anderen Worten: Der Entwickler hat etwas zu unternehmen. Oder?
Jein. Denn der User kann durchaus verantwortlich sein für den Auslöser des Fehlers, der Entwickler muss dies aber abfangen.

genau. Der Entwickler hat etwas zu unternehmen. Das Handling von fehlerhaften Eingaben gehört dazu.

Zuerst hätten aber mal die Entwickler von PHP was zu unternehmen.

Naja, nach und nach schieben sie PHP ja ein Konzept hinterher, wir dürfen also weiter hoffen ;-)

Beseitigung der textuellen Fehlermeldungen. Erzeugen einer eineindeutigen Fehlernummer, die man dann wieder mittels Funktion in einen fehlertext umsetzen kann, wenn es denn notwendig erscheint. Aber eine sichere Größe wegzurationalisieren und gegen eine vage zu ersetzen, das ist nicht professionell!

Ich sage nur "magic_*", was zum Glück mit PHP6 komplett entfällt ...

Cheatah

[Tom]

Hello,

ich arbeite derzeit an einem ErrorHandling-Objekt, quasi also Ersatz für die PHP eigene Fehlerbehandlungsroutine. Alle DB-Fehler, NOTICEs, WARNINGs, etc werden abgefangen, in einem Errorlog gesichert und es wird das PHP-Script vor Ausgabe des Templates gestoppt. Bis vor der Ausgabe des Templates (HTML-Codes) werden alle möglichen Meldungen abgefangen. Ist das gut so ?

Nein, nicht bedingungslos!

Es gibt böse Fehler und gute Fehler. Die muss man voneinender trennen, denn PHP kann das nicht alleine. Es hängt vom Kontext des Programmes ab, ob z.B. ein Dateiöffnungsfehler ein guter odr ein böser Fehler ist.

Und auch die Fehler- und Statusmeldungen und ihre Ausgabeeinheit (also entweder Standardausgabe zum Client oder Fehlerprotokoll für den Administrator) hängen vom Programmkontext ab.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[mod]

Es gibt böse Fehler und gute Fehler. Die muss man voneinender trennen, denn PHP kann das nicht alleine. Es hängt vom Kontext des Programmes ab, ob z.B. ein Dateiöffnungsfehler ein guter odr ein böser Fehler ist.

Erötere bitte näher

Gruß mod.

[Tom]

Hello,

Es gibt böse Fehler und gute Fehler. Die muss man voneinender trennen, denn PHP kann das nicht alleine. Es hängt vom Kontext des Programmes ab, ob z.B. ein Dateiöffnungsfehler ein guter odr ein böser Fehler ist.

Erötere bitte näher

401

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Es gibt böse Fehler und gute Fehler. Die muss man voneinender trennen, denn PHP kann das nicht alleine. Es hängt vom Kontext des Programmes ab, ob z.B. ein Dateiöffnungsfehler ein guter odr ein böser Fehler ist.
Erötere bitte näher

Als Beispiel wird eine Datei üblicherweise geöffnet, etwas eingetragen und sie dann wieder geschlossen. Wenn sie nicht da ist, gibt das zwar einen Datei-existiert-nicht-Fehler, aber dann kann man sie einfach anlegen. Das war sozusagen ein guter, also ein erwarteter Fehler. Und das Beispiel war ein schlechtes, denn man kann die Datei ja auch in den Modi w, w+, a oder a+ öffnen, dann wird sie bei Bedarf gleich mit erstellt.

Ein böser Fehler wäre, wenn in der Datei etwas wichtiges steht und sie nicht gefunden/gelesen werden kann.

dedlfix.

[dedlfix]

Tach!

ich arbeite derzeit an einem ErrorHandling-Objekt, quasi also Ersatz für die PHP eigene Fehlerbehandlungsroutine. Alle DB-Fehler, NOTICEs, WARNINGs, etc werden abgefangen, in einem Errorlog gesichert und es wird das PHP-Script vor Ausgabe des Templates gestoppt. Bis vor der Ausgabe des Templates (HTML-Codes) werden alle möglichen Meldungen abgefangen. Ist das gut so ?

Es ist sehr verlockend, eine einzige zentrale Stelle für die Fehlerbehandlung einzubauen, statt an jeder Stelle, an der Fehler auftreten können, eine eigene Reaktion zu implementieren. Das hat aber zur Folge, dass du nur noch allgemein auf Fehler reagieren kannst und dem Anwender nicht mehr die beste Alternative aus seiner Sicht in einer bestimmten Situation bieten kannst.

Wenn beispielsweise ein Bestellvorgang aus technischen Gründen nicht durchgeführt werden kann, sollte man den Anwender dabei unterstützen, seine Bestellung auf alternativem Weg auszuführen (vielleicht per Mail), sonst bestellt er bei der Konkurrenz. Also kann man den Fehler nicht nur generell abfangen und dem Anwender ein "System kaputt" präsentieren, sondern muss individuell in den else-Zweig was Sinnvolles, möglichst Zielerreichendes notieren. Dass zusätzlich der Administrator eine Benachrichtigung braucht, steht außer Frage. Auch dabei muss man manchmal differenzieren. Ist es nur etwas Unbedeutendes, muss man den Admin nicht aus dem Bett klingeln. Ist es hingegen ein kritischer Fehler in einem wichtigen produktiven System, wäre eine SMS oder ähnliches angebracht.

Was soll ich dem User für eine Fehlermeldung präsentieren? Vorschläge?

Eine Fehlermeldung sollte er nur zu sehen bekommen, wenn er dran schuld ist (zum Beispiel bei unerlaubten Eingabe). Ansonsten sollte er die System-kaputt-Meldung nur bekommen, wenn gar nichts anderes mehr geht.

In bereits zu diesem Thema behandelten Threads wurde darauf hingewiesen keine System-Infos auszugeben, wegen Sicherheit!

Ja, der Anwender kann mit der Meldung nichts anfangen. Das andere Extrem ist, das er die Informationen zu deinen Ungunsten ausnutzt.

dedlfix.

[mod]

Es ist sehr verlockend, eine einzige zentrale Stelle für die Fehlerbehandlung einzubauen, statt an jeder Stelle, an der Fehler auftreten können, eine eigene Reaktion zu implementieren. Das hat aber zur Folge, dass du nur noch allgemein auf Fehler reagieren kannst und dem Anwender nicht mehr die beste Alternative aus seiner Sicht in einer bestimmten Situation bieten kannst.

Bei DB-Fehlern, Warnings, Notices etc. gebe ich eine 'System kaputt' Meldung aus. Was Anderes halte ich für unverantwortlich. Wenn was vom Konzept abweicht muss das System gestoppt werden.

Wenn beispielsweise ein Bestellvorgang aus technischen Gründen nicht durchgeführt werden kann, sollte man den Anwender dabei unterstützen, seine Bestellung auf alternativem Weg auszuführen (vielleicht per Mail), sonst bestellt er bei der Konkurrenz. Also kann man den Fehler nicht nur generell abfangen und dem Anwender ein "System kaputt" präsentieren, sondern muss individuell in den else-Zweig was Sinnvolles, möglichst Zielerreichendes notieren. Dass zusätzlich der Administrator eine Benachrichtigung braucht, steht außer Frage. Auch dabei muss man manchmal differenzieren. Ist es nur etwas Unbedeutendes, muss man den Admin nicht aus dem Bett klingeln. Ist es hingegen ein kritischer Fehler in einem wichtigen produktiven System, wäre eine SMS oder ähnliches angebracht.

Nettes Beispiel! :-)

Eine Fehlermeldung sollte er nur zu sehen bekommen, wenn er dran schuld ist (zum Beispiel bei unerlaubten Eingabe). Ansonsten sollte er die System-kaputt-Meldung nur bekommen, wenn gar nichts anderes mehr geht.

Das ist implementiert, wird auch von den richtigen "Systemfehlern" unterschieden!

[dedlfix]

Tach!

Bei DB-Fehlern, Warnings, Notices etc. gebe ich eine 'System kaputt' Meldung aus. Was Anderes halte ich für unverantwortlich. Wenn was vom Konzept abweicht muss das System gestoppt werden.

Wie wäre es, das Konzept zu ändern und über Alternativen nachzudenken. Wenn ein unerwarteter Datenbankfehler auftritt, ist nur die Datenbank betroffen. Der Rest des Systems kann weiterarbeiten, falls das ohne das DBMS in irgendeiner Weise sinnvoll ist. Nach meiner Erfahrung bei einem Webprojekt, bei dem ich bei Fehlern Mails an mich haben senden lassen, passierte es gelegentlich, dass das DBMS temporär weg war und gleich danach wieder ging. Auf mein Shop-Beispiel bezogen: wenn das beim Produktkatalog-Stöbern passiert, wird es vermutlich keine Alternative geben, als den potenziellen Kunden um etwas Warten und einen erneuten Versuch zu bitten. Aber beim Bestellvorgang kann man den in der Session gesammelten Warenkorb durchaus an die Kundenbetreung mailen und muss nicht auf das Geschäft verzichten.

dedlfix.

[hotti]

hi,

ich arbeite derzeit an einem ErrorHandling-Objekt, quasi also Ersatz für die PHP eigene Fehlerbehandlungsroutine. Alle DB-Fehler, NOTICEs, WARNINGs, etc werden abgefangen, in einem Errorlog gesichert und es wird das PHP-Script vor Ausgabe des Templates gestoppt. Bis vor der Ausgabe des Templates (HTML-Codes) werden alle möglichen Meldungen abgefangen. Ist das gut so ?

Beim Entwickeln/Programmieren laufend ins Error-Log zu schauen ist zeitraubend.

Hotti

[Tom]

Hello,

ich arbeite derzeit an einem ErrorHandling-Objekt, quasi also Ersatz für die PHP eigene Fehlerbehandlungsroutine. Alle DB-Fehler, NOTICEs, WARNINGs, etc werden abgefangen, in einem Errorlog gesichert und es wird das PHP-Script vor Ausgabe des Templates gestoppt. Bis vor der Ausgabe des Templates (HTML-Codes) werden alle möglichen Meldungen abgefangen. Ist das gut so ?

Beim Entwickeln/Programmieren laufend ins Error-Log zu schauen ist zeitraubend.

Finde ich nicht. Ich lasse es immer mit tail -f error_log auf einem anderen Bildschirm mitlaufen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hi,

Beim Entwickeln/Programmieren laufend ins Error-Log zu schauen ist zeitraubend.

Finde ich nicht. Ich lasse es immer mit tail -f error_log auf einem anderen Bildschirm mitlaufen.

Ja, für sowas brauchst Du keine Error-Handling-Objects sondern einen zweiten Monitor ;)

Hotti