globe: selbstgebauten error_handler verstehen

Beitrag lesen

n'abend,

Weil es um einen völlig anderes Thema geht.

es geht immer noch um deinen error_handler. Vielleicht ein anderes Problem mit dem Ding, aber immer noch um das Ding. Den Code deines aktuellen error_handlers zu posten wäre auch kein Fehler gewesen, denn sofern ich trigger_error() richtig verstehe, hast du dir da eine (ungewollte) Rekursion eingebaut.

(b) warum fragst du in deinem error_handler nicht ab woher der Fehler kommt?

Weil mir das wenig weiterhilft. Die PearMail-Klasse ist Bestandteil von PHP und da ich bei einem ISP bin habe ich keinen Zugriff darauf.
/usr/local/lib/php/Mail/RFC822.php in line 586

Liegt der ganze PEAR-Kram in /usr/local/lib/php/?
Liegt da noch anderes Zeug außer der PEAR-Kram drin?
Kann das alles ignoriert werden?

if( strstr($pfad, '/usr/local/lib/php/') !== false ){ /* ich bin ein doofer PEAR Kram */ }

Ich will ja nicht gleich die Pear-Klasse ändern (weil: kann nicht). Die Frage war nur, wie man den Fehler umgehen kann.

Den PEAR-Kram brauchst du ja auch nicht ändern. Diesen mistigen Code will man in 95% aller PEAR-Produkte sowieso nicht sehen.

Immerhin bekommt man keine Fehlermeldung, wenn man keinen error hander benutzt. Und wie bereits erwähnt hilft es auch nicht, wenn ich es zu Testzwecken mit error_reporting(0) versuche. Da bekomme ich ihn auch.

Mal kurz in der Dokumentation von set_error_handler() nachschlagen bringt dich unweigerlich zur folgenden Aussage:
«Es ist wichtig und darf nicht vergessen werden, dass die standardmässige PHP Fehlerbehandlung vollkommen umgangen wurde. Die Einstellungen der Funktion error_reporting()  haben keine Auswirkung und Ihre eigene Fehlerbehandlungsroutine wird ohne Rücksicht darauf aufgerufen. Sie können jedoch immer noch den aktuellen Wert von error_reporting  lesen und entsprechend handeln.»

Sprich: Deinem error_handler ist scheiss egal was du für ein error_reporting gesetzt hast, da es diese Direktive schlichtweg ignoriert. Du musst also ein deinem error_handler selbst dafür sorgen, dass entsprechend irgendwelcher Bedingungen (z.b. durch auslesen des error_reporting levels) gehandelt wird.

Weiter steht dort:
«Von besonderer Bedeutung ist, dass dieser Wert 0 sein wird, falls der Befehl, der den Fehler verurscht hat, mit dem @ error-control operator versehen ist.»

Wo wir wieder bei der vorigen Aussage sind: Passe deinen error_handler entsprechend an - er wird ohne Rücksicht auf Verluste wegen jedem Pipifax aufgerufen.

Weiter steht dort:
«Beachten Sie auch, dass Sie die() aufrufen können, wenn es notwendig ist. Wenn die Fehlerbehandlungsfunktion zurückkehrt, wird die Ausführung des Skripts beim nächsten Befehl nach dem fehlerverursachenden Befehl fortgesetzt.»

Sprich: egal was da gerade passiert ist, wenn du im error_handler die Ausführung nicht abbrichst, wird dein Script weiterlaufen, als wäre nichts passiert (, was wahrscheinlich zu vielen weiteren Fehlern führen wird).

weiterhin schönen abend...

--
Freundlich wie man war, hat man mir Großbuchstaben geschenkt.
sh:( fo:# ch:# rl:| br:> n4:& ie:{ mo:} va:) de:] zu:} fl:( ss:? ls:[ js:|