nicht angemeldet
Tach!
sag mal, wie behandelst du (der Profi) denn Fehler* in einem Skript? Gibt es dazu eine best practice?
Am besten scheint mir, dass man sich zunächst mal bewusst ist, welche Fehler auftreten können. Da man das kaum bis zur Vollständigkeit vorausschauen kann, sollte man vor allem herausfinden, wie Fehler signalisiert werden. Dies steht im PHP-Handbuch beschrieben. In der Regel gibt eine Funktion im Fehlerfall etwas anderes zurück als im Gut-Fall. Wenn man diese Information im Code auswertet, dann ist das schon mal der erste wichtige Schritt. Und ja, mit Fehlerauswertungscode wird das Script unter Umständen um ein Vielfaches größer als wenn man nur die Sonnenscheinvariante programmiert.
Was macht man nun mit dem gefangenen Fehler? Kann man den Fehler voraussehen und kennt eine Alternative, wie der Besucher dennoch zu seinem Ziel kommen kann, dann sollte man diese implementieren. Wenn nicht, wäre eine Tröstmeldung in Richtung Anwender und eine Benachrichtigung in Richtung Administrator sinnvoll. Keinesfalls sollte man den genauen Fehlermeldungstext mit irgendwelchen Systeminterna drin ausgeben, und auch nicht einfach so das Script sterben lasen. Normalerweise kann der Anwender nichts für den auftretenden Fehler und er sollte auch nicht dafür mit einer Meldung bestraft werden, mit der er nichts anfangen kann.
* Eigentlich meine ich gar nicht zwingend PHP-Fehler, sondern eher Debug-Ausgaben oder eigene Fehler (zum Beispiel Unplausibilitäten oder fehlerhafte Validierung von Werten).
Debug-Ausgaben gebe ich unter PHP üblicherweise schlicht und einfach mit einem var_dump() aus. Ein <pre> davor spart bei komplexen Strukturen den Blick in die Quelltextansicht des Browsers. Debug-Ausgaben kommen nach dem Debugvorgang wieder raus, also gebe ich mir auch keine gesteigerte Mühe, sie schön aussehen zu lassen oder sie schön in die Ausgabe einzufügen. In dem Augenblick geht es darum, den Fehler im PHP-Code zu finden und dabei ist das Ergebnis im Browser nicht weiter relevant. Es muss deshalb auch kein valider Code entstehen, also ist ein schließendes </pre> unnötig.
Selbst erzeugte Fehlermeldungen, also beispielsweise wenn beim Validieren der Eingabewerte unerlaubte Werte festgestellt werden, sind nochmal eine andere Kategorie für sich. Die gehören ja zur Geschäftslogik und werden je nach deren Anforderung behandelt. Solche gehen auf die Kappe des Anwenders und müssen in Zusammenarbeit mit ihm geklärt werden.
Das waren die Varianten für überschaubare Projekte. Nun gibt es zum Beispiel auch noch Bibliotheken und andere wiederverwendbare Codestücke, bei denen man nicht weiß, in welcher Umgebung sie letztlich laufen werden. Da kann man gleich gar nicht einfach so Fehler ausgeben. Wenn man nicht selbst darauf reagieren kann, bleibt nur das ordentliche Melden an den Aufrufer, über eine Exception oder einen speziellen Rückgabewert.
Außerdem gibt es da noch die schwierigen Fälle, wenn sich der Fehler im Labor partout nicht nachstellen lässt. Dann bleibt nicht viel anderes übrig als den Code mit Log-Ausgaben zu spicken. Dafür gibt es fertig verwendbare Bibliotheken. Man muss dann "nur" noch seinen Code mit Log-Aufrufen spicken und einmal zentral definieren, wohin die Meldung gehen soll.
dedlfix.
Der Martin