nicht angemeldet
php fopen erfolglos
MudGuard
Julius
Rolf b
TS
AugeMoin,
Server A möchte von Server B eine Datei abrufen:
if ( $handle = fopen ( $url, "r")) {
…
} else {
…
}
Diese Datei darf leer sein. Bevor Else ausgeführt wird, erfolgt eine Fehlermeldung:
Warning: fopen(…): failed to open stream: HTTP request failed! HTTP/1.0 410 Gone in … on line 39
Wie kann ich die Fehlermeldung unterbinden?
Die aufgerufene Datei sendet header("HTTP/1.0 410 Gone")
Linuchs
-
Hi,
Warning: fopen(…): failed to open stream: HTTP request failed! HTTP/1.0 410 Gone in … on line 39
Wie kann ich die Fehlermeldung unterbinden?
eine URL aufrufen, die nicht gestorben ist?
cu,
Andreas a/k/a MudGuard-
eine URL aufrufen, die nicht gestorben ist?
Ob die URL gestorben ist, weiss ich vorher nicht. Ich möchte Veranstaltungstermine der nächsten 7 Tage. Die kann es geben oder nicht.
Wenn ich morgen dieselbe URL aufrufe, kann Inhalt kommen.
Linuchs
-
-
Hallo Linuchs,
Wie kann ich die Fehlermeldung unterbinden?
Ein
@vor den Funktionsaufruf packen:@fopen("blabla").fopenliefert in dem Fall dann ein false.Gruß
Julius-
Hi,
Wie kann ich die Fehlermeldung unterbinden?
Ein
@vor den Funktionsaufruf packen:@fopen("blabla").fopenliefert in dem Fall dann ein false.damit wird nicht die Fehlermeldung unterbunden, sondern nur die Ausgabe derselben.
cu,
Andreas a/k/a MudGuard-
Ja. Aber es scheint so gewollt. php.net sagt:
**Errors/Exceptions** If the open fails, an error of level E_WARNING is generated. You may use @ to suppress this warning.Das gilt für fopen und file_exists. D.h. um die Warnung zu vermeiden, müsste man vorher einen Directory Scan machen. Dazu hat man aber nicht unbedingt das Recht. Es scheint, als wäre @ hier unvermeidlich.
Rolf
-
Tach!
D.h. um die Warnung zu vermeiden, müsste man vorher einen Directory Scan machen. Dazu hat man aber nicht unbedingt das Recht. Es scheint, als wäre @ hier unvermeidlich.
Das @ ist vermeidlich, wenn es nur darum geht, eine Fehlermeldung in der Ausgabe wegzubekommen. Wenn man ein solches Problem hat, dann hat man eine für den Produktivbetrieb ungeeignete Einstellung von display_errors. Dieser Konfigurationswert sollte off/0 sein. Fehlermeldungen mit internen Informationen sollten in keinem Fall an den Besuchern präsentiert werden. Nicht nur aus sicherheitstechnischen Beweggründen, sie stören auch die Optik. Fehlermeldungen für den Administrator lässt man ins Logfile schreiben oder ihm auf anderem Wege zukommen. Das @ kann man aber auch dann verwenden, wenn die Fehlermeldung bekannt ist, und nicht geloggt werden muss, weil man sich bereits selbst um eine Behandlung kümmert. Zum Beispiel indem man das false geeignet auswertet.
dedlfix.
-
-
Hallo MudGuard,
Wie kann ich die Fehlermeldung unterbinden?
Ein
@vor den Funktionsaufruf packen:@fopen("blabla").fopenliefert in dem Fall dann ein false.damit wird nicht die Fehlermeldung unterbunden, sondern nur die Ausgabe derselben.
Wenn ich merke, dass das nicht funktioniert hat und ich ein false bekommen habe, kann ich das ja loggen (spamme mir aber nicht unnötig die Log-Dateien voll) und die URL ggf. aus der Liste entfernen – dann hätte ich die Ursache ja beseitigt.
Gruß
Julius-
Hello,
Hallo MudGuard,
Wie kann ich die Fehlermeldung unterbinden?
Ein
@vor den Funktionsaufruf packen:@fopen("blabla").fopenliefert in dem Fall dann ein false.damit wird nicht die Fehlermeldung unterbunden, sondern nur die Ausgabe derselben.
Wenn ich merke, dass das nicht funktioniert hat und ich ein false bekommen habe, kann ich das ja loggen (spamme mir aber nicht unnötig die Log-Dateien voll) und die URL ggf. aus der Liste entfernen – dann hätte ich die Ursache ja beseitigt.
Man kann/sollte sich dann auch die letzte Fehlermeldung holen, wenn man die automatische Behandlung unterdrückt hat.
siehe error_get_last
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
-
-
Hallo Julius,
Ein
@vor den Funktionsaufruf packen:@fopen("blabla").fopenliefert in dem Fall dann ein false.danke dir, das isses. Kenne ich vom @mysql... und dachte, es wäre eine Datenbank-Spezialität.
Gruß, Linuchs
-
Hallo Linuchs,
Ein
@vor den Funktionsaufruf packen:@fopen("blabla").fopenliefert in dem Fall dann ein false.danke dir, das isses. Kenne ich vom @mysql... und dachte, es wäre eine Datenbank-Spezialität.
Wahrscheinlich, um die deprecated-Warnung von PHP bzgl.
mysqlzu unterdrücken, oder?Da wäre es in der Tat besser bzw. sauberer, den Fehler zu beseitigen (auf etwas Anderes als
mysqlumstellen) oder zumindest übergangsweise die Konfiguration zu ändern und E_DEPRECATED abzustellen.Gruß
Julius-
Hallo
Ein
@vor den Funktionsaufruf packen:@fopen("blabla").fopendanke dir, das isses.
Wahrscheinlich, um die deprecated-Warnung von PHP bzgl.
mysqlzu unterdrücken, oder?Nicht unbedingt. Beispiel:
mysql_queryschmeißt bei einem Fehler unmittlebar eine Meldung, die man nicht haben will, gerade dann, wenn man auf den Rückgabewert anderweitig reagiert. Dass man die Meldung nicht dem Benutzer anzeigen will, kommt „nur noch“ oben drauf.Ansonsten hast du natürlich recht. Es ist Zeit, die alte MySQL-Bibliothek loszulassen.
Tschö, Auge
--
Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
Toller Dampf voraus von Terry Pratchett
-
-
-
-
gestrichen
@ war die Lösung. Dass die Datei nicht da ist, weißt Du ja schon...
-
Wie kann ich die Fehlermeldung unterbinden?
Falsche Frage und falsche Herangehensweise. Vielmehr muss Dein Code damit rechnen, dass eine bestimmte Ressource nicht verfügbar ist. Die Frage ist also, was Dein Programm in diesem Fall machen soll und diese Frage kannst nur Du selbst beantworten.
MfG
-
Tach!
Wie kann ich die Fehlermeldung unterbinden?
Falsche Frage und falsche Herangehensweise. Vielmehr muss Dein Code damit rechnen, dass eine bestimmte Ressource nicht verfügbar ist. Die Frage ist also, was Dein Programm in diesem Fall machen soll und diese Frage kannst nur Du selbst beantworten.
Die Frage ist nicht falsch, sie ist nur nicht ausreichend, wenn die Lösung lediglich die Unterdrückung sein soll. PHP hat nun mal die Eigenschaft, Fehlermeldungen auszugeben, selbst wenn man mit dem Fehler rechnet und Gegenmaßnahmen für sein Auftreten im Programm hat. Die Frage, wie man diese trotzdem erzeugten Meldungen aus der Ausgabe fernhält, ist legitim.
Es ist auch nicht immer sinnvoll, eine vorhergehende Prüfung vorzunehmen. Besonders bei solchen zeitaufwendigen Dingen wie Requests. Ein Request mit Ergebnisauswertung sollt ausreichen, statt einem, der eine Existenzprüfung vornimmt und einem weiteren, der sie dann abfragt. Und dann ist noch die Frage, ob die Existenzprüfung still ist oder ebenfalls eine Meldung erzeugt.
dedlfix.
-
Hello,
Die Frage ist nicht falsch, sie ist nur nicht ausreichend, wenn die Lösung lediglich die Unterdrückung sein soll. PHP hat nun mal die Eigenschaft, Fehlermeldungen auszugeben, selbst wenn man mit dem Fehler rechnet und Gegenmaßnahmen für sein Auftreten im Programm hat. Die Frage, wie man diese trotzdem erzeugten Meldungen aus der Ausgabe fernhält, ist legitim.
Viel schlimmer finde ich, dass php nur Fehlertexte erzeugt und keine eindeutigen Fehlernummern.
Ist das eigentlich in PHP > 5.6, also vermutlich PHP 7.x endlich korrigiert worden?Und wenn nicht, dann haben sie hoffentlich die Texte nicht geändert, sonst kann ich meine Sammlung wegwerfen.
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
Die Unterdrückung einer Fehlermeldung ist eine der möglichen Antworten auf die Frage, wie ein Programm damit umgeht, wenn Daten zur Ausgabe nicht verfügbar sind.
Es ist auch nicht immer sinnvoll, eine vorhergehende Prüfung vorzunehmen.
Du hast mit dieser Sichtweise ein typisches Henne-Ei-Problem, Antwort siehe oben. Sinnvoll ist es grundsätzlich immer, Systemfehlermeldungen so zu übersetzen, dass sie vom Anwender verstanden werden. Demzufolge ist das Unterdrücken von Fehlermeldungen als Lösung überhaupt nicht vertretbar -- weder für den Entwickler, noch für den Anwender.
MfG
-
Tach!
Sinnvoll ist es grundsätzlich immer, Systemfehlermeldungen so zu übersetzen, dass sie vom Anwender verstanden werden. Demzufolge ist das Unterdrücken von Fehlermeldungen als Lösung überhaupt nicht vertretbar -- weder für den Entwickler, noch für den Anwender.
Als Lösung nicht, aber als Teil der Lösung, weil sie ansonsten für den Anwender sichtbar werden und Informationen ausgeben, die den Anweder im besten Fall nicht interessieren. Deine Antworten hier sind zwar generell nicht verkehrt, aber sie berücksichtigen die konkreten Umstände beim Arbeiten mit PHP nur ungenügend. Deswegen meine Einwände.
dedlfix.
-
-
-