Hi,
unterdrückte Warnungen können die Fehlersuche erheblich erschweren.
Aus Bequemlichkeit werden nicht selten einige PHP Funktionen für Zwecke benutzt, bei denen ein Erfolg nicht immer gegeben ist.
Ein typischer Fall ist ein file_get_contents auf die URL eines nicht immer verfügbaren Servers.
Im Falle des Misserfolges werden werden Warnungen geworfen, die für diesen Fall unterdrückt werden sollen.
Nun gibt es ja den bei Anfängern beliebten Fehler-Kontroll-Operator @, doch dieser ist nicht umsonst verpönt,
denn er unterdrückt alle Fehler. Beispiel mit falsch geschriebenen Funktionsnamen:
Spannend wird die Problematik für ein include.
Hier sollen gezielt nur Warnungen vom include der obersten Ebene unterdrückt werden.
Angeregt durch nikoschs Ausführungen hier im Forum entstand folgende Lösung:
Fehler, Notizen und Warnungen, die nicht vom include kommen, werden alle ausgegeben.
So auch alle Warnungen, die im Falle eines Erfolges aus dem include-File kommen.
Um die Wirkung des eigenen Error-Handlers sichtbar zu machen, muß nur die Zeile mit 'set_error_handler...' mal auskommentiert werden.
Dann sehen wir alle include-Warnungen wie gewohnt.
Wofür nun dieser 'Aufwand' ?
Ich habe bisher nur einen Fall wo ich es brauche.
Es ist ein Autoloader, in dem mit include verschiedene Muster von Dateinamen/Pfaden bis zum Erfolg probiert werden müssen.
Gegenüber der Variante per is_readable alle Kombinationen von include-Pfaden und Dateinamesmuster zu prüfen,
ist der Aufwand dieser Lösung hier noch klein und mit nur sehr geringen Einbußen in Bezug auf die Scriptlaufzeit.
Probleme bisher keine, alle Tests liefen zufriedenstellend.
Eine Kleinigkeit wird sich noch in der Praxis zeigen, ob die Bedingung
eventuell noch zu weich ist und durch ein regEx ersetzt werden muss.
Kommentare sind jedoch immer willkommen.
LG jspit
unterdrückte Warnungen können die Fehlersuche erheblich erschweren.
Aus Bequemlichkeit werden nicht selten einige PHP Funktionen für Zwecke benutzt, bei denen ein Erfolg nicht immer gegeben ist.
Ein typischer Fall ist ein file_get_contents auf die URL eines nicht immer verfügbaren Servers.
Im Falle des Misserfolges werden werden Warnungen geworfen, die für diesen Fall unterdrückt werden sollen.
Nun gibt es ja den bei Anfängern beliebten Fehler-Kontroll-Operator @, doch dieser ist nicht umsonst verpönt,
denn er unterdrückt alle Fehler. Beispiel mit falsch geschriebenen Funktionsnamen:
PHP-Code:
//so nicht!
$r = @file_get_content('testdatei.txt'); //Keine Fehlermeldung
Hier sollen gezielt nur Warnungen vom include der obersten Ebene unterdrückt werden.
Angeregt durch nikoschs Ausführungen hier im Forum entstand folgende Lösung:
PHP-Code:
<?php
error_reporting(-1);
$errHandler = function ($errcode, $errmsg, $fileName, $line) {
return $errcode == E_WARNING
&& strpos($errmsg,'include(') !== false
&& $fileName == __FILE__ ;
};
set_error_handler($errHandler);
//include, das eine Warnung erzeugen würde
$include_ok = include 'noexist.php';
//Nutzung einer undefinierten Konstante
$include2_ok = include myincludeName;
//Funktionsaufruf der Warnung erzeugt
$include3_ok = include file_get_contents('dateiname.txt');
restore_error_handler();
var_dump('include results:',$include_ok,$include2_ok,$include3_ok);
So auch alle Warnungen, die im Falle eines Erfolges aus dem include-File kommen.
Code:
Notice: Use of undefined constant myincludeName ... on line 15 Warning: file_get_contents(dateiname.txt) ...failed to open stream ... on line 17 string(20) " include results:" bool(false) bool(false) bool(false)
Dann sehen wir alle include-Warnungen wie gewohnt.
Wofür nun dieser 'Aufwand' ?
Ich habe bisher nur einen Fall wo ich es brauche.
Es ist ein Autoloader, in dem mit include verschiedene Muster von Dateinamen/Pfaden bis zum Erfolg probiert werden müssen.
Gegenüber der Variante per is_readable alle Kombinationen von include-Pfaden und Dateinamesmuster zu prüfen,
ist der Aufwand dieser Lösung hier noch klein und mit nur sehr geringen Einbußen in Bezug auf die Scriptlaufzeit.
Probleme bisher keine, alle Tests liefen zufriedenstellend.
Eine Kleinigkeit wird sich noch in der Praxis zeigen, ob die Bedingung
PHP-Code:
strpos($errmsg,'include(') !== false
Kommentare sind jedoch immer willkommen.
LG jspit
Kommentar