Wrapper für trigger_error

[strauberry]

Hallo zusammen,

in meiner Anwendung habe ich ein eigenes Exception-Handling. Mit trigger_error() funktioniert das auch alles wunderbar. Jetzt möchte ich aber nicht trigger_error aufrufen sondern $app->throwException(). In dieser Methode würde dann erst trigger_error() gestartet. Das Problem ist, dass errorLine und errorFile IMMER die Stelle angeben, an der trigger_Error aufegerufen wurde und nicht, wo throwException gestartet wurde. Ist ja auch logisch, aber wie kann ich das umgehen? Also dass in den Parametern meines eigenen ExceptionHandlers richtige Werte für $errorLine und $errorFile stehen?

DANKE!

strauberry

[jahlives]

Also dass in den Parametern meines eigenen ExceptionHandlers richtige Werte für $errorLine und $errorFile stehen?

Und wenn du

$app->throwException(debug_backtrace()); 

machst?

[onemorenerd]

Also wenn schon, dann doch eher so:

$app->throwException('Example error', E_USER_ERROR);

class app {
    public function throwException($err_msg, $err_type) {
        $trace = debug_backtrace();
        trigger_error($err_msg, $err_type);
    }
} 

Das siehst du auch schon, wo der Hase im Pfeffer liegt:
trigger_error() wird in app::throwException() aufgerufen und die PHP-Fehlermeldung wird immer die Stelle des Calls referenzieren. Im obigen Codesample wäre das Zeile 6.
Es gibt keine Möglichkeit, die Zeilennummer aus $trace an trigger_error() weiterzugeben.

Mußt du eigentlich für PHP <5 entwickeln oder warum willst du nicht wirklich Exceptions werfen?

[jahlives]

Aber er will doch die Zeile

wo throwException gestartet wurde

Und die müsste doch in debug_backtrace() beim Aufruf der Methode throwException enthalten sein. Oder irre ich mich da?

warum willst du nicht wirklich Exceptions werfen?

Das wäre sicherlich die sauberste Lösung...

Gruss

tobi

[strauberry]

Vielen Dank schon mal für die Tipps!

Ich entwickel auf PHP 5. Keine "richtigen" Exceptions schmeißen, hmmm. Ich überleg momentan sowieso, wieso ich das mit dem trigger_error mache. Denn in meinem eigenen ExceptionHandler rufe ich dann auch wieder eigene Methoden auf. DIe könnte ich doch auch direkt aufrufen, wenn es eine Exception gibt. Mit debug_backtrace() könnte ich an diese Methoden dann auch alle Daten übergeben.

[onemorenerd]

Original geschrieben von jahlives
Und die müsste doch in debug_backtrace() beim Aufruf der Methode throwException enthalten sein. Oder irre ich mich da?

Ich nehme an, er will in app::throwException() nur deswegen noch trigger_error() aufrufen, damit er die PHP-eigenen Fehlerbehandlungsroutinen nutzen kann (Fehlermeldung erzeugen, ins Log schreiben und ggf. ausgeben).
Das bringt ihm aber nichts, weil er die Daten aus dem Backtrace nicht in die Fehlermeldung rein bekommt - man kann trigger_error() keine Zeilennummer übergeben. PHP holt sich die aus dem Parsetree.

Aber wenn er sowieso eigene Fehlerbehandlungsroutinen implementiert, kann er auch gleich das Verhalten von trigger_error() nachbauen. Ist ja nicht so schwer, er braucht nur ini_get(), error_log() und echo.
Auf trigger_error() kann er dann völlig verzichten.

[BugBite]

Das normale Exception handling von PHP funktioniert doch super ?!

class ParameterException extends Exception{
...
}

throw new ParameterException("Falscher Parameter");

try {...}
catch(Exception $e){
$e->getMessage();
} 

usw.
was man hald so von exceptions erwartet
kannst auch print stack trace machen etc...

[strauberry]

Ok, sehr schön :-) dann verzichte ich auf die PHP-Fehlerroutinen und baue diese lieber selbst nach.
Das ganze läuft nach MVC und mir ist wichtig, dass ich die einzelnen Teile problemlos austauschen kann. Und da bin ich mit eigenen Routinen wesentlich flexibler.

Vielen Dank euch! (brauchte nur nochmal Bestätigung, dass das nicht absolut müllig ist :-) )

[onemorenerd]

Richtig schick wäre

class app {
    private static $_instance;    // Singleton
    private function __construct() {}    // Singleton
    private function __clone() {}    // Singleton

    public static function getInstance() {
        set_exception_handler(array('app', 'exceptionHandler'));
        if (null === self::$_instance) self::$_instance = new self();
        return self::$_instance;
    }
    public static function exceptionHandler($e) {
        // Fehlerbehandlung
    }
} 

[strauberry]

Das mit dem Singleton ist schon drin :-) Bei deinem Vorschlag hab ich jetzt aber ja auch wieder die PHP-Fehlerroutinen und wenn ich in meinem Script $app->throwException mache, kommt wieder das Zeilenproblem... ich werde auf den error-handler ganz verzichten, denke ich und in meine eigenen ExceptionHandler die Funktionalitäten einbauen...

[tontechniker]

Das mit dem Singleton ist schon drin :-) Bei deinem Vorschlag hab ich jetzt aber ja auch wieder die PHP-Fehlerroutinen und wenn ich in meinem Script $app->throwException mache, kommt wieder das Zeilenproblem... ich werde auf den error-handler ganz verzichten, denke ich und in meine eigenen ExceptionHandler die Funktionalitäten einbauen...

Wo? Von Fehler steht bei onemorenerd garnichts. Den Unterschied zwischen Errorhandling und Exceptions kennst du aber oder?
Statt etwas eigenes zu basteln solltest du vernünftig die PHP Exceptions benutzen (am besten für jegliche Fehler). Wenn du dann irgendwo im Code davon ausgehst das ein Fehler auftreten könnte fängst du sie entsprechend ab und reagierst darauf.

[onemorenerd]

Du hast zu schnell gelesen. Ich schrieb set_exception_handler, nicht error. Es ziehlt darauf ab, Exceptions aller Art zu fangen. So mußt du nicht $app->throwException() aufrufen, sondern kannst einfach sagen:
throw new Exception()

Die Singleton-Konstruktion sollte nur ein Schmankerl sein, weil es naheliegend ist, dass eine Klasse namens app nicht mehrfach instanziert werden sollte.