Version 0
Vor circa einem halben Jahr begannen wir damit, Fehler nicht mehr nur vom Kunden finden zu lassen oder zu ignorieren, sondern sie kontrolliert zu behandeln. Im ersten Anlauf (eine kleine Hau-Ruck-Lösung, ich geb's ja zu) haben wir ein extra Script in REDAXO injiziert, das sich als Error Handler (set_error_handler) ins System gehängt hat und bei jedem Fehler (darin sind auch Warnungen und Hinweise eingeschlossen) eine eMail an uns schickte. Damit hatten wir einen durchaus brauchbaren Überblick über Fehler der Website, nachdem diese auf dem Server des Kunden gelandet ist. In der eMail waren neben IP, User-Agent, Zeitpunkt und weiteren statistischen Daten auch ein Stacktrace und der Inhalt der globalen $_GET, $_POST, $_COOKIE und $_SERVER enthalten. Ein Traum, wenn es an das Finden von Fehlern ging.
Vorteile
Das ganze brachte große Vorteile für alle, die am Projekt beteiligt waren:
- Der Kunde muss uns nicht mehr Screenshots schicken, nur um festzustellen, dass der für uns interessante Teil fehlt. Er muss sich auch die Fehlermeldung nicht mehr merken oder sie extra in eine eMail an uns kopieren. Im Regelfall wissen wir bereits vor dem Kunden, dass es irgendwo geknallt hat.
- Der Entwickler muss nicht mehr raten, wie der Fehler zustande kam. Er hat direkt einen Stacktrace und den globalen Systemzustand zur Hand und muss nicht traurig sein, dass der Kunde diese wertvollen Daten nicht (nach)liefern kann. Auch muss er den Kunden weniger oft bitten, zu beschreiben, was er getan hat, um den Fehler zu produzieren.
- Zu guter Letzt freut sich auch der Vertrieb, wenn weniger Mails reinkommen, die als Bugs im internen Ticket-System eingetragen werden müssen. Immerhin gehen die eMails direkt an den oder die Entwickler. Und weil Fehler, die nicht korrigiert werden, den Entwickler auf Dauer nerven, werden sie auch schneller behoben -- einfach nur, um Ruhe zu haben.
So toll die eMails auch sind, so schlecht sind sie integriert. Ist das Script einmal eingebunden, werden alle Fehler abgefangen. Macht man lokal Fehler, versucht PHP, eMails zu verschicken -- unter Windows schlägt das i.d.R. aufgrund des fehlenden SMTP-Servers fehl. Auch die Konfiguration war etwas hakelig und unschön.
Um das ganze Konzept etwas in geregelte Bahnen zu lenken, haben wir uns entschlossen, die Funktionalität als AddOn neu umzusetzen.
Funktionen
Das AddOn stellt zwei Umgebungen zur Verfügung: Produktion und Entwicklung. Beziehungsweise Production und Development auf Neudeutsch.
- In der Produktiv-Umgebung werden Fehler keinesfalls angezeigt. Sie werden stattdessen auf dem Server protokolliert und -- auf Wunsch -- per eMail verschickt. Diese Umgebung wählen wir also, wenn der Code auf dem Server läuft und die Website bereits live ist.
- In der Entwicklungs-Umgebung werden Fehler ebenfalls nicht mehr dort angezeigt, wo sie auftreten. Stattdessen werden sie gesammelt und inklusive Stacktrace und Code-Ausschnitt in einem HTML-Overlay angezeigt. Gleichzeitig werden auch SQL-Queries geloggt und in einem Overlay angezeigt (inklusive abgerufener Datensätze und dafür benötigter Zeit).
Error-Level-Auswahl
[ externes Bild ]
Einstellungen im Production-Environment
[ externes Bild ]
Aufgetretene Fehler
[ externes Bild ]
Download
Wir sind zuversichtlich, mit diesem AddOn einen kleinen Beitrag zur Qualitätssicherung von Redaxo-Projekten zu leisten. Da der Error Handler nur einen Aufsatz auf REDAXO darstellt, kann man ihn einfach deaktivieren, falls er doch Probleme machen sollte (Ticket erstellen nicht vergessen!).
Das AddOn ist für REDAXO 4.1 und 4.2.x verfügbar und basiert auf unseren Developer Utils, die neben grundlegenden Funktionen auch das Backend von REDAXO leicht anpassen. Es wird unter MIT-Lizenz veröffentlicht. Für die Funktionalität im Frontend muss auf der Seite (zur Zeit) jQuery eingebunden sein (was bei uns bei allen Seiten der Fall ist).
Download des AddOns Error Handler v1.1.4
(ca. 360 KB, für REDAXO 4.1 bis 4.2.x)
Einen kleinen Schönheitsfehler hat die Sache jedoch: Um Zugriff auf die SQL-Queries zu haben, muss bei der Installation der Developer Utils die Klasse rex_sql gepatched werden. Wer dort keine Veränderungen vorgenommen hat, muss sich keine Gedanken machen. Andernfalls sollte man dringends davon absehen, die Developer Utils zu installieren, da sonst die eigenen Änderungen verlorengehen.
Quellcode
Neben dem eigentlichen Download für alle, die das AddOn einfach nur konsumieren möchten, sei an dieser Stelle auch noch auf das öffentliche Repository bei Bitbucket verwiesen. Wir freuen uns über Mithilfe und Feedback jeder Art. Sei es in Form von Patches oder via Forks. Einzige Voraussetzung ist ein installierter Mercurial-Client (für Windows: Mercurial Command Line, TortoiseHg, MercurialEclipse, Merclipse, ...). Feedback und Patches dann bitte direkt an mich (christoph@webvariants.de). Ich freu mich drauf
Grüße,
Christoph
Hinweis: Bei diesem Beitrag handelt es sich um eine schamlose Kopie des dazugehörigen Blogbeitrags.
), ist das Query Logging im aktuellen Error Handler komplett nutzlos. Erwarte nicht, dass dir dort irgendwann einmal etwas gezeigt wird. 
![[ externes Bild ]](http://blog.webvariants.de/wp-content/uploads/2009/11/error-handler-levels-600x201.png){kind=link}
![[ externes Bild ]](http://blog.webvariants.de/wp-content/uploads/2009/11/error-handler-production-600x334.png){kind=link}
![[ externes Bild ]](http://blog.webvariants.de/wp-content/uploads/2009/11/error-handler-errors-600x305.png){kind=link}
![[ externes Bild ]](http://img242.imageshack.us/img242/4034/errorhandler.jpg){kind=link}
