dedlfix: selbstgebauten error_handler verstehen

Beitrag lesen

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";