In PHP nur noch Exceptions statt Fehlermeldungen

Du hast keine Lust mehr auf die doofen Fehlermeldungen in PHP? Dann kannst du das mit set_error_handler erreichen. Davor bitte die Doku dazu lesen!

Hier mal ein Beispiel, wie sowas aussehen könnte:

set_error_handler('throwException', E_ALL);
function throwException($fehlercode, $fehlertext, $fehlerdatei, $fehlerzeile){
    throw new ErrorException($fehlertext, $fehlercode, 0, $fehlerdatei, $fehlerzeile);
}
trigger_error("foo-bar", E_ERROR);

Übrigens erzeugt “trigger_error” den Fehler nicht weil “trigger_error” aufgerufen wurde, sondern weil “trigger_error” “E_ERROR” als zweiten Parameter nicht akzeptiert. Ein echter E_ERROR also. :)
Leider ist es (noch) nicht möglich, für jeden Fehler Typen einen eigenen Handler zu definieren um zum Beispiel E_NOTICE Fehler anders zu behandeln als E_ERROR. Als zweiten Parameter akzeptiert set_error_handler (laut Doku) nur E_ALL oder E_STRICT. Könnte mir aber gut vorstellen, dass man das irgendwie austricksen kann.
Ich habe übrigens die ErrorException Klasse gewählt, da diese auch Dateiname und Zeile akzeptiert … wenn man diese Info schon mal hat, kann man diese ja auch gleich verwenden.
Als letzten Parameter kann man in der callback Funktion noch “$errcontext” verwenden – der Inhalt ist bei einer Exception jedoch etwas fehl am Platz.

Nun wünsch ich allen die das wollen viel Spaß, denn damit wird das PHP Standard Fehler Handling ausgehebelt. Sowas wie z.B. “$resource = @fopen($irgendEineDatei);” funktioniert dann nämlich nicht mehr bzw. ergibt eine schöne Exception falls ein Fehler auftritt. Das ist vor allem dann nervig, wenn man fremden Code einsetzt, der sich auf solche Konstrukte verlässt.

4 Antworten auf In PHP nur noch Exceptions statt Fehlermeldungen

  1. Fabian sagt:

    Zu Handlern für unterschiedliche Typen: Ja, das kann man austricksen, man kapsle einfach den error handler in eine Klasse, die sich den vorigen error handler merkt (Rückgabewert von set_error_handler) und diesen im error handler ggf. wieder aufruft. So kann man sich eine error handler chain aufbauen und die einzelnen handler nur bestimmte Typen behandeln lassen.
    Wenn dabei die error reporting Einstellung (und somit auch der @ Operator) beachtet werden soll, muss dieses nur noch im handler abgefragt werden (mit bitwise and: if (error_reporting() & $errCode)) { ... })
    Übrigens, fatale Fehler mit trigger_error werden so erzeugt: trigger_error("foo-bar", E_USER_ERROR);

    Und zum individuellen behandeln fataler Fehler lässt sich register_shutdown_function missbrauchen, einen Ansatz habe ich hier beschrieben: Fatal Error Handler

    • Rudi sagt:

      Ach so! $errCode entspricht E_ERROR, E_WARNING und so weiter?! Ist ja fast offensichtlich. Irgendwie stand ich da auf dem Schlauch. =)
      Auf jeden Fall kann man dann die einzelnen Typen ja auch im Error Handler unterschiedlich behandeln!

      “Übrigens, fatale Fehler mit trigger_error werden so erzeugt: trigger_error(“foo-bar”, E_USER_ERROR);”
      => das war Absicht um einen echten E_ERROR zu erzeugen:
      “Übrigens erzeugt „trigger_error“ den Fehler nicht weil „trigger_error“ aufgerufen wurde, sondern weil „trigger_error“ „E_ERROR“ als zweiten Parameter nicht akzeptiert. Ein echter E_ERROR also. :)”

  2. Warum verwendest du nicht einfach den Fehlercode, um verschiedene Exceptions auszulösen? Die verschiedenen Werte und dazugehörigen Konstanten stehen im Manual: http://de.php.net/manual/de/function.error-reporting.php

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Log Out / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Log Out / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Log Out / Ändern )

Verbinde mit %s

Follow

Get every new post delivered to your Inbox.