Mail/RFC822.php meldet: "Undefined variable: comments"

[lixx]

Hi!

Habe wieder ein error handler problem.

Nachdem ich den error handler implementiert hatte, bekam ich von PearMail bei der Funktion

Mail_RFC822::parseAddressList($email, '', true);

den Fehler

Notice: Undefined variable: comments"

angezeigt. Kann man das eleganter umgehen als error_reporting auf E_ALL ^ E_NOTICE zu setzen (was übrigens auch nichts nützt). Ich hätte nämlich schon gerne auch die E_NOTICE ausgegeben bekommen. Nur eben nicht von der Pear-Klasse.

Seltsamerweise gibt er sie auch aus, wenn ich error_reporting auf (0) setze ... ?

Den errorHandler gibt's übrigens schon hier: http://forum.de.selfhtml.org/?t=140187&m=910779

lg lixx

[globe]

n'abend,

Den errorHandler gibt's übrigens schon hier: http://forum.de.selfhtml.org/?t=140187&m=910779

(a) wieso bleibst du dann nicht in deinem Thread?
(b) warum fragst du in deinem error_handler nicht ab woher der Fehler kommt?
In $filename bekommst du doch den Pfad zur Datei übergeben, in der der Fehler auftrat. Brauchst ja nur prüfen ob die Fehlermeldung aus irgendeiner kap0tten™ PEAR-Geschichte kommt.

weiterhin schönen abend...

[lixx]

(a) wieso bleibst du dann nicht in deinem Thread?

Weil es um einen völlig anderes Thema geht.

(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.

In $filename bekommst du doch den Pfad zur Datei übergeben, in der der Fehler auftrat.

/usr/local/lib/php/Mail/RFC822.php in line 586

Brauchst ja nur prüfen ob die Fehlermeldung aus irgendeiner kap0tten™ PEAR-Geschichte kommt.

Ich will ja nicht gleich die Pear-Klasse ändern (weil: kann nicht). Die Frage war nur, wie man den Fehler umgehen kann. 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.

lg lixx

[globe]

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...

[lixx]

Danke, das hilft mir schon weiter.

Eine Frage noch: Wenn man nun Fehler loggen, also in eine Datei schreiben lassen möchte, benötigt man doch einen error handler. Aber wenn man einen error handler hat, werden die Fehler, wie du sagst ignoriert und das Script läuft weiter. Gibt es aber eine Möglichkeit die Fehler zu loggen, ohne das normale Fehlerverhalten zu ändern?

lg lixx

[dedlfix]

echo $begrüßung;

Ich weiß ja nicht, was den lieben globe so an PEAR verstört hat ... aber der Fehler mit dem nicht initialisierten $comments ist in der aktuellen Version von Mail_RFC822 beseitigt. Außerdem trat er in Mail_RFC822::validateMailbox() auf, nicht in Mail_RFC822::parseAddressList(), denn da kommt diese Variable gar nicht vor. In der älteren Version wird in der Tat nicht dafür gesorgt, dass $comments wirklich existiert. Stattdessen wird beim einem der lesenden Zugriffe ein @ davorgesetzt. Und es betrifft nicht nur fremde Scripte sondern auch deinen Code, wenn du ihn mit @ versiehst. Beispielsweise ist es für getimagesize() notwendig, den @ zu verwenden, da bei Nicht-Grafikdateien diese Funktion eine Warnung ausgibt, man aber keine gescheite Möglichkeit hat, vorher den Dateiinhalt auf eine Grafik zu testen. Abert das ist ja, wie das Handbuch ausführt, kein Problem, wenn man im Error-Handler das aktuelle Error-Level ermittelt (if (error_reporting() != 0) ...)

Bei PEAR ist man nicht auf Gedeih und Verderb auf die beim Hoster installierte Version angewiesen. Man kann sich die benötigten Pakete auch einzeln und in aktuell holen und in einem Unterverzeichnis seines Hosting-Platzes unterbringen. (Am besten geschieht dies außerhalb des DocumentRoots. Ordentliche Provider lassen es zu, dass man seine Domains auf Unterverzeichnisse des eigenen Speicherplatzes verweisen lässt und hat damit einen solchen Außerhalb-DocumentRoot-Bereich.) Nun muss nur noch der include_path angepasst werden ...

Eine Frage noch: Wenn man nun Fehler loggen, also in eine Datei schreiben lassen möchte, benötigt man doch einen error handler.

Nein.

Gibt es aber eine Möglichkeit die Fehler zu loggen, ohne das normale Fehlerverhalten zu ändern?

Das Kapitel Error Handling and Logging Functions erzählt dir auch was über die Konfigurationsparameter log_errors und error_log.

echo "$verabschiedung $name";

[lixx]

Außerdem trat er in Mail_RFC822::validateMailbox() auf, nicht in Mail_RFC822::parseAddressList()...

Da kann ich auch nix machen. Bei mir kam auf jeden Fall der Fehler mit dem Aufruf der Methode parseAddressList.

Stattdessen wird beim einem der lesenden Zugriffe ein @ davorgesetzt. Und es betrifft nicht nur fremde Scripte sondern auch deinen Code, wenn du ihn mit @ versiehst.

Das hatte ich auch schon versucht, aber bei Methoden scheint das nicht zu funktionieren. Und der Fehler trat auf, als ich die Methode aufrief, aber nicht beim include-Befehl.

Bei PEAR ist man nicht auf Gedeih und Verderb auf die beim Hoster installierte Version angewiesen. Man kann sich die benötigten Pakete auch einzeln und in aktuell holen und in einem Unterverzeichnis seines Hosting-Platzes unterbringen. ...

Das hatte ich ganz am Anfang versucht, bevor ich dahintergekommen bin, dass PearMail ein bestandteil von PHP ist. Aber da wollte er mir die Klasse nicht erstellen, da sie ja bereits vorhanden war. Das mit dem include_path ist jetzt neu. Aber den ändern will ich auch nicht.

Aber ist ja auch egal.

... Dein Hinweis mit dem Konfigurationsparameter log_errors ist genau das was ich suchte. Die Meldung ist jetzt nicht so umfangreich (z.B. ohne REMOTE_ADDR, etc.) aber sie genügt mir schon mal.

danke für eure hilfe & lg
lixx

[dedlfix]

echo $begrüßung;

Stattdessen wird beim einem der lesenden Zugriffe ein @ davorgesetzt. Und es betrifft nicht nur fremde Scripte sondern auch deinen Code, wenn du ihn mit @ versiehst.

Das hatte ich auch schon versucht, aber bei Methoden scheint das nicht zu funktionieren. Und der Fehler trat auf, als ich die Methode aufrief, aber nicht beim include-Befehl.

Natürlich wirkt der @ auch bei Methoden. Jedoch wird bei einem benutzerdefinierten Error-Handler, wie schon gesagt, keinerlei Einstellung des error_reporting-Wertes berücksichtigt. Dieser Handler wird bei einem Fehler immer aufgerufen, auch dann, wenn das error_reporting permanent oder mit einem @ temporär auf 0 gesetzt wurde.

echo "$verabschiedung $name";