if(@
0 
Felix Riesterer
if(@
AugeHallo,
ich habe PHP Code gesehen, bei dem folgendes vorkommt:
if(@irgendeine_funktion($Parameter)==false){
...
}
Meine Frage:
Was bedeutet das @ Zeichen?
MFG
rap
-
Liebe(r) rap,
Was bedeutet das @ Zeichen?
es unterdrückt Fehlermeldungen.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Moin!
Was bedeutet das @ Zeichen?
es unterdrückt Fehlermeldungen.
Und das ist nie eine gute Idee, denn Fehlermeldungen haben immer einen Grund, den es abzustellen gilt!
Vernünftige Programmierer arbeiten ohne @.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hello,
Vernünftige Programmierer arbeiten ohne @.
Könntest Du diese Quirksaussage bitte auch mit vernünftigem[tm] Inhalt füllen?
Wie bekommt man eine aussagefähige Fehlernummer in PHP?
Ich kenne nur Text-Fehlermeldungen, die man abfragen kann, wenn man
in der Variablen php_errormsg abholen kann, wenn man track_errors eingeschaltet hat.Aufmerksame Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Vernünftige Programmierer arbeiten ohne @.
Könntest Du diese Quirksaussage bitte auch mit vernünftigem[tm] Inhalt füllen?
Wie bekommt man eine aussagefähige Fehlernummer in PHP?
Sinn?? Jedenfalls nicht mit @, auch nicht ohne @.
Mathias
-
Hello,
Vernünftige Programmierer arbeiten ohne @.
Könntest Du diese Quirksaussage bitte auch mit vernünftigem[tm] Inhalt füllen?
Wie bekommt man eine aussagefähige Fehlernummer in PHP?
Sinn?? Jedenfalls nicht mit @, auch nicht ohne @.
Wie jetzt "Sinn??"
Hat Dein Posting einen Mehrwert?Wenn Du die Abfragemöglichkeit meinst, die Du in https://forum.selfhtml.org/?t=177719&m=1171009 erwähnt hast, dann sollte dazu aber gesagt werden, dass es die erst seit PHP >=5.2.0 gibt.
Außerdem liefert sie immer noch keine qualifizierte Fehlernummer passend zum Text aus $php_errormsg, sondern nur eine grobe Fehlerklasse (type=>), die wenig hilfreich für die Laufzeitbehandlung ist.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo,
Wie jetzt "Sinn??"
Ich habe mich nur gefragt, wie du von @ plötzlich auf die Fehlernummer kommst. Aber vielleicht hast du nur die günstige Gelegenheit zum Threaddrift genutzt. ;)
Mathias
-
Hello,
Wie jetzt "Sinn??"
Ich habe mich nur gefragt, wie du von @ plötzlich auf die Fehlernummer kommst. Aber vielleicht hast du nur die günstige Gelegenheit zum Threaddrift genutzt. ;)
Oh, da sehe ich, vergleichen mit der Fehlernummergenauigkeit von PHP absolut null Drift im Thread.
@ hat mit der Unterdrückung von Meldungen auf der Konsole zu tun und da frage ich mich doch ganz legitim, was man denn sonst mit den Meldungen anfangen sollte.
Ich denke, dass hier überhaupt keine Drift vorliegt, lediglich eine gewisse Bandbreite, deren Güte aber immer noch erstaunlich hich ist. Außer Deinem Posting zu Chistoph Kummer allerdings, das ist ein Ausreißer :-)
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo.
Oh, da sehe ich, vergleichen mit der Fehlernummergenauigkeit von PHP absolut null Drift im Thread.
[...]
Ich denke, dass hier überhaupt keine Drift vorliegt, lediglich eine gewisse Bandbreite, deren Güte aber immer noch erstaunlich hich ist.
Oh, ein klassischer i/o-Fehler.
MfG, at
-
-
-
-
-
echo $begrüßung;
Wie bekommt man eine aussagefähige Fehlernummer in PHP?
Die Frage lässt sich ganz einfach mit einem "gar nicht" beantworten. Wenn es Fehlernummern gäbe, müssten die beim Erzeugen einer Fehlermeldung in PHPs Quellcode zu finden sein. Beispielsweise deine Fehlermeldung von neulich in fgets(). Zu finden in http://cvs.php.net/viewvc.cgi/php-src/ext/standard/file.c?revision=1.529&view=markup ab Zeile 1119. In Zeile 1138 wird die Fehlermeldung erzeugt.
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Length parameter must be greater than 0");
Es ist lediglich das Level E_WARNING zu sehen. Die Aufgabe des ersten Arguments ist mir nicht ganz klar, hat aber was mit einem Thread Safe Resource Manager zu tun und ist keine Fehlernummernkonstante.
Wenn du unbedingt eindeutige Fehlernummern brauchst, musst du dazu erstmal die passende Infrastruktur im PHP-Code durchgesetzt bekommen.
echo "$verabschiedung $name";
-
Hello dedlfix
Wie bekommt man eine aussagefähige Fehlernummer in PHP?
Die Frage lässt sich ganz einfach mit einem "gar nicht" beantworten.
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Length parameter must be greater than 0");
Zu dieser internen Funktion war ich auch schon vorgestoßen und habe voller entsetzen festgetellt, dass dort ein klar definierter Fehler (C errno) i.d.R. mittels dieser Funktion lokal in einen Text umgewandelt wird. 2338 unterschiedliche Zuweisungen, zumindest im mir vorliegenden Quellcode.
Wenn du unbedingt eindeutige Fehlernummern brauchst, musst du dazu erstmal die passende Infrastruktur im PHP-Code durchgesetzt bekommen.
Das ist sehr, sehr traurig.
Dabei hätte man errno nur weiterreichen müssen in eine ebensolche globale Variable, wie $php_errormsg. Das hätte fürs erste schon gereicht.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
echo $begrüßung;
Dabei hätte man errno nur weiterreichen müssen in eine ebensolche globale Variable, wie $php_errormsg. Das hätte fürs erste schon gereicht.
Es gibt aber nicht nur den Fall, dass man einen vorhandenen Code nur weiterzureichen braucht. PHP erzeugt ja auch eigene Meldungen, und die müssten irgendwie von den von anderen Stellen generierten Fehlernummern abgegrenzt werden.
Die Frage ist letzlich: Wieviel gewinnt man insgesamt mit solchen Fehlernummern und wieviel Aufwand bedeutet es, Nummern einzuarbeiten und vor allem zu pflegen.
echo "$verabschiedung $name";
-
-
-
Moin!
Hello,
Vernünftige Programmierer arbeiten ohne @.
Könntest Du diese Quirksaussage bitte auch mit vernünftigem[tm] Inhalt füllen?
Wenn du dir die Gesamtaussage aus https://forum.selfhtml.org/?t=177719&m=1170958 nochmal betrachtest, zielte diese in eine andere Richtung, als du jetzt willst.
Wie bekommt man eine aussagefähige Fehlernummer in PHP?
Jedenfalls nicht mit oder ohne @.
Das @ verhindert, dass die eventuell auftretende Fehlermeldung ausgegeben wird. Fehler auf diese Weise zu unterdrücken ist schlecht, weil man als Programmierer von ihnen eigentlich immer Kenntnis haben möchte, um sie von vornherein zu verhindern, sie abzufangen oder zumindest drauf zu reagieren.
Weil es natürlich für den unwissenden Anwender nicht schön aussieht, wenn ihm da mitten in der Seite so eine Fehlermeldung ins Auge springt, hat PHP etliche Methoden integriert, wie man genau das verhindern kann, ohne sich auf das Vorhandensein von @ zu verlassen.
Methode 1:
display_errors = no
log_errors = yesIn Produktivumgebungen gehören Fehler nicht öffentlich angezeigt, sondern in ein Logfile.
Methode 2:
set_error_handler()Mit einer eigenen Fehlerbehandlungsfunktion kann die Ausgabe von Fehlermeldungen für behebbare Fehler beliebig gestaltet, also auch unterbunden bzw. in eine Datei geloggt werden.
Im übrigen entspricht es meiner Erfahrung, dass sämtliche PHP-Funktionen bei validen Aufrufen je nach Erfolg entweder ein nutzbares Ergebnis oder aber explizit "false" zurückgeben. Ein ungeprüftes Weiterarbeiten mit dem Funktionsergebnis, welches normalerweise als erfolgreich erwartet wird, führt unweigerlich zu vermeidbaren PHP-Fehlermeldungen - der Klassiker dürfte sein, dass mysql_fetch_array() Fehler wirft, weil mysql_query() zuvor gescheitert ist aufgrund eines fehlerhaften SQL-Querys.
Ich kenne nur Text-Fehlermeldungen, die man abfragen kann, wenn man
in der Variablen php_errormsg abholen kann, wenn man track_errors eingeschaltet hat.Da das @ nichts mit der Abfragbarkeit spezieller Fehlermeldungen zu tun hat, frage ich mich, wie du auf diesen Aspekt kommst.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hello,
Da das @ nichts mit der Abfragbarkeit spezieller Fehlermeldungen zu tun hat, frage ich mich, wie du auf diesen Aspekt kommst.
Ja, wie komme ich jetzt nur von
"Vernünftige Programmierer arbeiten ohne @."
auf die Frage, wie denn vernünftige Programmierer arbeiten würden?
Durch Denken?
Es hat aber scheinbar keinen Zweck, mit Dir eine Diskussion zu führen, die Mit- und Weiterdenken im Themenbereich ermöglicht. Du bist zu sehr damit beschäftigt, Deine vorgefertigten Aussagen zu verteidigen. Ich verstehe nur nicht, warum Du sie dann überhaupt beginnst, wenn Andere dann doch nichts dazu beitragen dürfen!
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hi Tom,
Es hat aber scheinbar keinen Zweck, mit Dir eine Diskussion zu führen, die Mit- und Weiterdenken im Themenbereich ermöglicht. Du bist zu sehr damit beschäftigt, Deine vorgefertigten Aussagen zu verteidigen. Ich verstehe nur nicht, warum Du sie dann überhaupt beginnst, wenn Andere dann doch nichts dazu beitragen dürfen!
Also auf mich wirken die gesammelten Postings von dir auf diesen Thread wie eine beleidigte Leberwurst, die versucht ihre "Widersacher" bei jeder Gelegenheit eins auszuwischen. Was ist dein Problem? Was haben dir die Poster, die du angreifst getan? Du drehst dich im Kreis? Du argumentierst vor dich hin, irgendwohin. Deine Bezüge zu den Textteilen der anderen sind für mich nicht nachvollziehbar. Was möchtest du erreichen? Was möchtest du hören?
ciao
romy-
Hello,
Also auf mich wirken die gesammelten Postings von dir auf diesen Thread wie eine beleidigte Leberwurst, die versucht ihre "Widersacher" bei jeder Gelegenheit eins auszuwischen.
Welche Widersacher?
Hier gibt es doch nur vernünftige Poster.
Und mit dem Fortgang des Threads bin ich auch zufrieden.Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
Hai,
Es hat aber scheinbar keinen Zweck, mit Dir eine Diskussion zu führen, die Mit- und Weiterdenken im Themenbereich ermöglicht. Du bist zu sehr damit beschäftigt, Deine vorgefertigten Aussagen zu verteidigen.
'Schuldigung, wenn ich jetzt zu direkt werde, aber ich habe da mal eine Frage an Dich:
Tom, bist Du wirklich sooo strunz bloed, wie du dich hier verhaeltst?
Ich meine, bei allem Respekt: DAS, was DU jetzt kritisiert, haben WIR DIR (=deiner Person) vorgeworfen.
Und dass Du jetzt GENAU DAS als Argument gegen Sven anbringst, ist einfach nur laecherlich.
Einfach nur laecherlich.- DU bist es, der keine Diskussion fuehren kann
- DU bist es, der keine Fragen beantwortet
- DU bist es, der hier mit "vorgefertigte Aussagen" um sich schmeisst
- DU bist es, der absolut keinen einzigen Fehler einsehen mag
- Und DU bist es, der Sachen erzaehlt, von denen er keinen Blassen schimmer hat.
Tom, es stehen immer noch etliche Frage aus, die Du beantworten solltest.
Solange Du die nicht beantwortet hast, ist jegliche Aussage von deiner Person
absolut keinen einzigen Cent wert.MfG,
Sympatisant--
"If the future isn't bright, at least it is colorful"
-
-
Das @ verhindert, dass die eventuell auftretende Fehlermeldung ausgegeben wird. Fehler auf diese Weise zu unterdrücken ist schlecht, weil man als Programmierer von ihnen eigentlich immer Kenntnis haben möchte, um sie von vornherein zu verhindern, sie abzufangen oder zumindest drauf zu reagieren.
Ach Sven: Wieso erzählst du denn diese Leier, wenn der Stand der Diskussion schon längst darüber hinaus ist? Das mag ja als Schwarz-Weiß-Faustregel stimmen, aber tricky wirds doch erst in der Grauzone.
Auf Fehler kann man je nach Anwendung von @ dennoch reagieren und dass man »eigentlich immer Kenntnis« von ihnen haben möchte, wurde im Thread auch schon widerlegt - zumindest will man es nicht bei manchen Warnings und Notices, die einfach uninteressant sind, wenn man eben z.B. den Rückgabewert des mit @ versehenen Aufrufs zur Fehlerbehandlung verwendet.
Mit einer eigenen Fehlerbehandlungsfunktion kann die Ausgabe von Fehlermeldungen für behebbare Fehler beliebig gestaltet, also auch unterbunden bzw. in eine Datei geloggt werden.
Ist doch Unsinn, jeden Befehl, dessen Warnings und Notices man antizipiert, durch einen eigenen Error-Handler zu kapseln...
Im übrigen entspricht es meiner Erfahrung, dass sämtliche PHP-Funktionen bei validen Aufrufen je nach Erfolg entweder ein nutzbares Ergebnis oder aber explizit "false" zurückgeben.
Ja, aber dabei gerne überflüssige Notices und Warnings absondern.
Mathias
-
-
-
Grüße,
Vernünftige Programmierer arbeiten ohne @.
manchmal überprüft man etwas mit einem if(), um eben den fehlerfall zu bearbeiten, allerdings wäre dann die zusätzliche fehlermeldiung unerwünscht. was dann?
MFG
bleicher--
__________________________-
Die Essenz der Egomanie
ie:{ fl:( br:< va:| ls:[ fo:# rl:? n4:? ss:| de:> js:| ch:| sh:( mo:| zu:|-
Hallo
Vernünftige Programmierer arbeiten ohne @.
manchmal überprüft man etwas mit einem if(), um eben den fehlerfall zu bearbeiten, allerdings wäre dann die zusätzliche fehlermeldiung unerwünscht. was dann?
Dann behebe man (im Entwicklungsstadium) den Fehler, auf dass er nicht mehr auftritt und somit auch nicht angezeigt wird.
Tschö, Auge
-
Grüße,
Dann behebe man (im Entwicklungsstadium) den Fehler, auf dass er nicht mehr auftritt und somit auch nicht angezeigt wird.
normalbeispiel - man versucht was aud der SQldatenbank mit ein paar generic parametrn zu holen, wenn das ergebniss sich nicht mit mysql_fetch_assoc() erfassen lässt, greift der else{ teil mit fehlerbehandlung.
man kriegt es aber uach mit der fehlermeldung zu tun.was wäre die empfohlene methode, außer @?
MFG
bleicher--
__________________________-
Die Essenz der Egomanie
ie:{ fl:( br:< va:| ls:[ fo:# rl:? n4:? ss:| de:> js:| ch:| sh:( mo:| zu:|-
Hello,
normalbeispiel - man versucht was aud der SQldatenbank mit ein paar generic parametrn zu holen, wenn das ergebniss sich nicht mit mysql_fetch_assoc() erfassen lässt, greift der else{ teil mit fehlerbehandlung.
man kriegt es aber uach mit der fehlermeldung zu tun.was wäre die empfohlene methode, außer @?
Bleib mal bitte bei PHP.
Da ist es schon kompliziert genug, qualifizierte Fehlerbehandlung durchzuführen.MySQL-Fehler abzufangen, ist hingegen wieder einfach, weil MySQL zumindest eine vernünftige[tm] Fehlerbehandlung besitzt.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo
Grüße,
Dann behebe man (im Entwicklungsstadium) den Fehler, auf dass er nicht mehr auftritt und somit auch nicht angezeigt wird.
normalbeispiel - man versucht was aud der SQldatenbank mit ein paar generic parametrn zu holen, wenn das ergebniss sich nicht mit mysql_fetch_assoc() erfassen lässt, greift der else{ teil mit fehlerbehandlung.
man kriegt es aber uach mit der fehlermeldung zu tun.Wo?
was wäre die empfohlene methode, außer @?
Man fange den Fehler ab. In deinem Beispiel kann es sich z.B. um MySQL-Fehler handeln. Diese werden aber durch die Rückgabewerte der benutzen Funktionen ruchbar.
$sql = mysql_connect(HOST,USER,PASS); // gibt im fehlerfall false zurueck if ($sql===false) { // Fehlerbehandlung } else { // weiter im (Quell-)Text }Folge: Es kommen keine Fehler durch und @ ist oblolet.
Tschö, Auge
-
Hallo,
$sql = mysql_connect(HOST,USER,PASS); // gibt im fehlerfall false zurueck
if ($sql===false) {
Manche Funktionen geben einen Rückgabewert zurück, den man auf false prüfen kann, schmeißen davon abgesehen aber noch eine Notice. Solche erwartete Notices sind uninteressant, weil man mit dem Rückgabewert bereits eventuelle Fehler behandelt. Ein Logging dieser Meldungen macht daher auch keinen Sinn. Ich glaube, das ist auch für mysql\_connect der Fall. Ich will es jetzt aber nicht ausprobieren oder nach anderen Beispielen suchen. Ich bin nur schon häufig auf solche Situationen gestoßen, wo mir dann $returnValue = @funktion() sinnvoll erschien. Oder wo ich einen Befehl mit set\_error\_handler/restore\_error\_handler gekapselt habe, um erwartete Warnungen aus er Ausgabe / dem Log heraus zu halten. Mathias -- [SELFHTML aktuell Weblog](http://aktuell.de.selfhtml.org/weblog/)-
Hello,
Ich glaube, das ist auch für mysql_connect der Fall. Ich will es jetzt aber nicht ausprobieren oder nach anderen Beispielen suchen. Ich bin nur schon häufig auf solche Situationen gestoßen, wo mir dann $returnValue = @funktion() sinnvoll erschien. Oder wo ich einen Befehl mit set_error_handler/restore_error_handler gekapselt habe, um erwartete Warnungen aus er Ausgabe / dem Log heraus zu halten.
Ich denke, dass man da frühzeitig Fehlerkanal und Nutzkanal voneinander trennen sollte.
Ich habe mir daher angewöhnt, auch schon bei der Entwicklung (komplexerer Lösungen) alle Fehlermelungen in eine Datei umzulenken und die in einer eigenen Konsole mittels "tail -f error_log" laufen zu lassen.
Oder eben entsprechende Anzeigemöglichkeit bei Windows-Umgebungen...
Dann kann man die Einstellungen von Anfang an so wählen, als wäre man im Life-Betrieb.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo
$sql = mysql_connect(HOST,USER,PASS); // gibt im fehlerfall false zurueck
if ($sql===false) {
> > Manche Funktionen geben einen Rückgabewert zurück, den man auf false prüfen kann, schmeißen davon abgesehen aber noch eine Notice. Ja, [Toms Beispiel](https://forum.selfhtml.org/?t=177719&m=1171001) ist so eines (mit WARNING). > Solche erwartete Notices sind uninteressant, weil man mit dem Rückgabewert bereits eventuelle Fehler behandelt. Ein Logging dieser Meldungen macht daher auch keinen Sinn. > Ich glaube, das ist auch für mysql\_connect der Fall. ... Eine fehlende/gescheiterte DB-Verbindung ist für den Admin bestimmt interessant. Entweder sind die Verbindungsdaten defekt/manipuliert oder der Server läuft nicht. MMn ein Fall für's Logging. Aber klar, es gibt (haufenweise) Fehler, die zur Laufzeit abgefangen aber nicht in das Log gehören. Den Benutzer gehen sie natürlich nichts an (Ausnahmen bestätigen die Regel). Tschö, Auge -- Die deutschen Interessen werden am Liechtenstein verteidigt. [Veranstaltungsdatenbank Vdb 0.2](http://termindbase.auge8472.de/) -
echo $begrüßung;
Ich bin nur schon häufig auf solche Situationen gestoßen, wo mir dann $returnValue = @funktion() sinnvoll erschien. Oder wo ich einen Befehl mit set_error_handler/restore_error_handler gekapselt habe, um erwartete Warnungen aus er Ausgabe / dem Log heraus zu halten.
Meinst du, dass du deinen selbstgeschreibenen Error-Handler temporär durch einen Dummy-Handler ersetzt, damit eine erwartete Meldung nicht geloggt wird? Wenn das der Fall wäre: Man kann ge-@-te Meldungen im Error-Handler am Rückgabewert vom parameterlos aufgerufenen error_reporting() erkennen. Der ist dann nämlich 0.
echo "$verabschiedung $name";
-
-
-
-
Hello,
Dann behebe man (im Entwicklungsstadium) den Fehler, auf dass er nicht mehr auftritt und somit auch nicht angezeigt wird.
Und was ist mit Laufzeitfehlern?
Meistens geht es um diese!Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo
Dann behebe man (im Entwicklungsstadium) den Fehler, auf dass er nicht mehr auftritt und somit auch nicht angezeigt wird.
Und was ist mit Laufzeitfehlern?
Meistens geht es um diese!Beispiel? ich weiß nicht, worauf du hinaus willst.
Tschö, Auge
-
Hello,
Und was ist mit Laufzeitfehlern?
Meistens geht es um diese!Beispiel? ich weiß nicht, worauf du hinaus willst.
Ok, wich will mal versuchen, Dich da ins Bild zu setzen:
$fh = fopen($dateiname, 'rb+');
Sollte keinerlei Meldungen auslösen, wen die Datei vorhanden ist, für den Scriptuser lesbar und schreibbar ist, und nicht gerad durch einen anderen Prozess durch dio_Funktionen geöffnet und gesperrt ist.
Du siehst also aus dem obigen Satz, dass eine Reihe von Laufzeitbedingungen vorhanden ist:
- Datei existiert im Zeitpunkt des Zugriffes (ein vorheriges file_exists() taugt nichts)
- Datei ist nicht gesperrt durch einen Prozess, der DIO benutzt
- Datei ist lesbar für den anfordernden Prozess
- Datei ist beschreibbar für den anforderden ProzessDies sind vier Fehlermöglichkeiten, die mir spontan einfallen. dazu gibt es in Netzen auch noch weitere Fehler, wie z.B.
- fehlende Netzwerkverbindung
- fehlende rechte im Netzwerkund wahrscheinlich habe ich noch ein paar Möglichkeiten vergessen.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo
Und was ist mit Laufzeitfehlern?
Beispiel? ich weiß nicht, worauf du hinaus willst.
Ok, wich will mal versuchen, Dich da ins Bild zu setzen:
$fh = fopen($dateiname, 'rb+');
Sollte keinerlei Meldungen auslösen, wen die Datei vorhanden ist, für den Scriptuser lesbar und schreibbar ist, und nicht gerad durch einen anderen Prozess durch dio_Funktionen geöffnet und gesperrt ist.
Du siehst also aus dem obigen Satz, dass eine Reihe von Laufzeitbedingungen vorhanden ist:
- Datei existiert im Zeitpunkt des Zugriffes (ein vorheriges file_exists() taugt nichts)
- Datei ist nicht gesperrt durch einen Prozess, der DIO benutzt
- Datei ist lesbar für den anfordernden Prozess
- Datei ist beschreibbar für den anforderden Prozess
Dies sind vier Fehlermöglichkeiten, die mir spontan einfallen. dazu gibt es in Netzen auch noch weitere Fehler, wie z.B.
- fehlende Netzwerkverbindung
- fehlende rechte im Netzwerk
Das Manual zu fopen sagt: "Scheitert das Öffnen der Datei, gibt die Funktion FALSE zurück.". Also prüfe ich darauf.
Dein obiger Code gibt mir die erwartete Warnung aus. Mit der nachfolgenden Prüfung (s.u.) bleibt die Warnung da, da der Fehler ja vor der Prüfung auftritt.
if ($fh===false) { echo "<p>Konnte Datei nicht öffnen.</p>"; } else { echo "<p>Datei wurde geöffnet.</p>"; }Aber genau das ist doch ein Paradebeispiel dafür, dass man sich während der Entwicklung sämtliche Fehler ausgeben lassen soll, um sie auszumerzen, und im Produktiveinsatz derartige Fehler in ein für den Anwender nicht zugängliches Log gehören. Dabei ist es völlig egal, warum der Fehler auftritt. Deine ersten víer Punkte liegen unmittelbar in der Verantwortung des Entwicklers bzw. Administrators der Anwendung. Das sollte auch für den Punkt 6 (fehlende Rechte im Netzwerk) gelten. Einzig die fehlende Netzwerkverbindung kann (ohne Manipulationen[1]) zur Laufzeit auftreten.
Wenn nun Fehlermeldungen in der Ausgabe unterbunden sind (mMn vorzugsweise skriptweit und nicht befehlsgebunden) und stattdessen in ein Log geschrieben werden sowie eine angemessene Meldung an den Anwender geht (z.B. "Ihre Anfrage konnte nicht ausgeführt werden, eine Meldung an den Betreiber ...") ist die Aufgabe "Fehler abfangen" nach meiner Meinung erfüllt. Im Log steht dann ja der Grund für den Fehler.
[1] Mit Manipulationen meine ich z.B. einen Angriff auf den Server mit Löschung der zu lesenden Datei.
Tschö, Auge
-
Hello,
Aber genau das ist doch ein Paradebeispiel dafür, dass man sich während der Entwicklung sämtliche Fehler ausgeben lassen soll, um sie auszumerzen,
Laufzeitfehler treten aber eben erst während der Laufzeit auf.
Wenn ein anderer Prozess in Deiner Multiuser-Umbegung die Datei gerade gelöscht hat, dann wüsste meiner das gerne, warum er die datei nun nicht öffnen kann, obwohl sie auf seinem Bildschirm doch noch gelistet ist..Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo
Aber genau das ist doch ein Paradebeispiel dafür, dass man sich während der Entwicklung sämtliche Fehler ausgeben lassen soll, um sie auszumerzen,
Laufzeitfehler treten aber eben erst während der Laufzeit auf.
Wenn ein anderer Prozess in Deiner Multiuser-Umbegung die Datei gerade gelöscht hat, dann wüsste meiner das gerne, warum er die datei nun nicht öffnen kann, obwohl sie auf seinem Bildschirm doch noch gelistet ist..Dann benutze das schon erwähnte set_error_handler. Da kannst deine eigenen Fehlernummern und -meldungen definieren. Darum ging es dir doch?
Wobei eine PHP-eigene Struktur mit feststehenden Fehlernummern, ähnlich wie bei MySQL, die Sache grundsätzlich vereinfachen würde, weil man diese Struktur nicht selbst erstellen müsste.
Tschö, Auge
-
Hello,
Dann benutze das schon erwähnte set_error_handler. Da kannst deine eigenen Fehlernummern und -meldungen definieren. Darum ging es dir doch?
Wenn Du es mal selber ausprobierst, wirst Du feststellen, dass die über set_error_handler() erhältlichen Fehlerinformationen dieselben sind, wie sie jetzt über die vereinfachte Funktion error_get_last() erhältlich sind.
siehe hierzu https://forum.selfhtml.org/?t=177719&m=1171028
Es geht doch um nichts anderes, als ein Pendant dzu errno aus C/C++ auch in PHP zur Verfügung zu haben. Ich verstehe nicht, warum die PHPler sich da so standhaft weigern das entsprechend weiterzuleiten, zumal sie ja Fehlerstrings erzeugen lassen, die genügend Unterscheidungskraft hätten.
Aber warum muss man jetzt erst wieder die Strings parsen oder zumindest vergleichen, um qualifiziert reagieren zu können?
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo
Dann benutze das schon erwähnte set_error_handler. Da kannst deine eigenen Fehlernummern und -meldungen definieren. Darum ging es dir doch?
Wenn Du es mal selber ausprobierst, wirst Du feststellen, dass die über set_error_handler() erhältlichen Fehlerinformationen dieselben sind, wie sie jetzt über die vereinfachte Funktion error_get_last() erhältlich sind.
siehe hierzu https://forum.selfhtml.org/?t=177719&m=1171028
Das ist mir bei der Lektüre von set_error_handler und error_reporting (Parameterliste) auch aufgegangen.
Es geht doch um nichts anderes, als ein Pendant dzu errno aus C/C++ auch in PHP zur Verfügung zu haben.
Aber warum muss man jetzt erst wieder die Strings parsen oder zumindest vergleichen, um qualifiziert reagieren zu können?
Weil es (leider) keine Fehlernummern gibt?
Tschö, Auge
-
Hello,
Aber warum muss man jetzt erst wieder die Strings parsen oder zumindest vergleichen, um qualifiziert reagieren zu können?
Weil es (leider) keine Fehlernummern gibt?
Mein Gott, er hat es!
[soll jetzt nur eine Persiflage auf My Fair Lady sein, keinesfalls eine Geringschätzung Deiner Person :-)]
Und genau diesen Missstand prangere ich seit Jahren an. Man kann deshalb in PHP mMn keine vernünftige[tm] Fehlerbehandlung betreiben, qed.
Svens Quirks-Spruch war also überflüssig. Oder ich habe das Ironiezeichen übersehen ;-)
Es ist demnach durchaus verständlich, dass PHP-Programmierer kurzerhand das @ einsetzen, um zumindest die Konsolenmeldungen zu verhindern. Dass das nicht der richtige[tm] Weg ist, haben wir ja in diesem Thread schon angesprochen. Dedlfix wollte ja immer schon einen Artikel über die richtige Fehlerbehandlung in PHP-Scripten verfassen, wenn ich das richtig in Erinnerung habe. Das ist auch wirklich notwendig, denn so wirklich Überblick hat doch keiner, was da Sache ist. das hat mir zumindest dieser Thread wieder gezeigt.
Ich wäre jedenfalls gerne dabei, wenn wir die Fakten hier nochmal zusammentragen wollten, ohne uns gegenseitig als Idioten zu bezeichnen (hat ja glücklicherweise noch keiner gemacht...).
Die geübten Quellcode-Leser könnten uns hier ganz bestimmt als erste helfen und uns verraten, wo errno versickert und in $php_errormsg umgewandelt wird.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo
Aber warum muss man jetzt erst wieder die Strings parsen oder zumindest vergleichen, um qualifiziert reagieren zu können?
Weil es (leider) keine Fehlernummern gibt?
Mein Gott, er hat es!
[soll jetzt nur eine Persiflage auf My Fair Lady sein, keinesfalls eine Geringschätzung Deiner Person :-)]
Hoff' ich doch.
Und genau diesen Missstand prangere ich seit Jahren an. Man kann deshalb in PHP mMn keine vernünftige[tm] Fehlerbehandlung betreiben, qed.
Das Rumpfriemeln in den Strings ist natürlich suboptimal, auch wenn sie zumindest dem menschlichen Leser ansagen, was Ambach ist. Andererseits, wieviele verschiedene Fehlernummern bräuchte es schon alleine für die mit PHP standardmäßig ausgelieferten Funktionen?
... ohne uns gegenseitig als Idioten zu bezeichnen (hat ja glücklicherweise noch keiner gemacht...).
Naja, dein Ton (wenn auch nicht allein deiner) war an mehreren Stellen aber recht grenzwertig.
Tschö, Auge
-
Hello,
Naja, dein Ton (wenn auch nicht allein deiner) war an mehreren Stellen aber recht grenzwertig.
Das sollte nicht so sein. Da bitte ich doch um Entschuldigung.
Aber zum Thema:
im Programm regelt die Fehlerauswertung jedenfalls eine Funktion "php_error_docref", die da bei allen möglichen Fehlern aufgerufen wird. Und wie es scheint, werden die Klartextmeldungen immer erst im Fehlerfall zugewiesen.
Und das in 2238 Zeilen in der Version, die mir vorliegt.
Beispiele:
php-5.2.5\ext\standard\basic_functions.c(4250): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Couldn't find constant %s", Z_STRVAL_PP(const_name));
php-5.2.5\ext\standard\basic_functions.c(4275): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid in_addr value");
php-5.2.5\ext\standard\basic_functions.c(4280): php_error_docref(NULL TSRMLS_CC, E_WARNING, "An unknown error occured");
php-5.2.5\ext\standard\basic_functions.c(4311): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unrecognized address %s", address);
php-5.2.5\ext\standard\basic_functions.c(4318): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unrecognized address %s", address);
php-5.2.5\ext\standard\basic_functions.c(4428): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Safe Mode warning: Cannot override protected environment variable '%s'", pe.key);
php-5.2.5\ext\standard\basic_functions.c(4450): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Safe Mode warning: Cannot set environment variable '%s' - it's not in the allowed list", pe.key);
php-5.2.5\ext\standard\basic_functions.c(4504): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid parameter syntax");
php-5.2.5\ext\standard\basic_functions.c(4643): php_error_docref(NULL TSRMLS_CC, E_WARNING, "No support for long options in this build");
php-5.2.5\ext\standard\basic_functions.c(4740): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Number of seconds must be greater than or equal to 0");
php-5.2.5\ext\standard\basic_functions.c(4763): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Number of microseconds must be greater than or equal to 0");
php-5.2.5\ext\standard\basic_functions.c(4793): php_error_docref(NULL TSRMLS_CC, E_WARNING, "nanoseconds was not in the range 0 to 999 999 999 or seconds was negative");
php-5.2.5\ext\standard\basic_functions.c(4818): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Sleep until to time is less than current time");
php-5.2.5\ext\standard\basic_functions.c(4932): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Argument 1 invalid");
php-5.2.5\ext\standard\basic_functions.c(4939): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid arguments");
php-5.2.5\ext\standard\basic_functions.c(4948): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid arguments");
php-5.2.5\ext\standard\basic_functions.c(4959): php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid arguments");
php-5.2.5\ext\standard\basic_functions.c(5010): php_error_docref(NULL TSRMLS_CC, E_WARNING, "TCP/IP option not available!");Es ist daher nicht sichergestellt, dass diese Fehlermeldungen wirklich harmonisiert sind, Sie werden im Fehlerfall ( C errno != 0) immer idnividuell zusammengestellt.
Das ist eigentlich überhaupt nicht lustig.
Ich hoffe ja immer noch, dass ich mich irre.Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
echo $begrüßung;
Dedlfix wollte ja immer schon einen Artikel über die richtige Fehlerbehandlung in PHP-Scripten verfassen, wenn ich das richtig in Erinnerung habe.
Eigentlich habe ich nur die Idee, dass ein Artikel über grundlegende Fehlersuche für Anfänger nützlich wäre. Das ist das was einem Großteil der PHP-Frager offensichtlich fehlt.
Das ist auch wirklich notwendig, denn so wirklich Überblick hat doch keiner, was da Sache ist. das hat mir zumindest dieser Thread wieder gezeigt.
Da ich nie das Bedürfnis hatte, Fehlermeldungsinhalte programmatisch auszuwerten, um darauf unterschiedlich reagieren zu können, und den meisten ja die die()-"Reaktion" reicht, sollte das nicht viel mehr werden als Logging für den Admin und Tröstmeldung für den Anwender.
echo "$verabschiedung $name";
-
Hello,
Da ich nie das Bedürfnis hatte, Fehlermeldungsinhalte programmatisch auszuwerten, um darauf unterschiedlich reagieren zu können, und den meisten ja die die()-"Reaktion" reicht, sollte das nicht viel mehr werden als Logging für den Admin und Tröstmeldung für den Anwender.
Naja, Du kannst schließlich auch nichts wieder hineinzaubern, was von den Entwicklern - warum auch immer - auf ach so umständliche Weise vernichtet wurde.
Ich hatte mal damit angefangen, die wensentlichen Textmeldungen wieder zurückzuwandeln in reaktionsgeeignete Fehlernummern. Die wichtigsten liegen doch ohnehin im Bereich Umgang mit Dateien.
Als nächstes würde mir dann Speichernutzung, noch verfügbarer Speicher, usw. einfallen. Aber das bekommt man wohl noch recht gut hin.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
-
-
-
-
-
-
-
-
-
Hello,
manchmal überprüft man etwas mit einem if(), um eben den fehlerfall zu bearbeiten, allerdings wäre dann die zusätzliche fehlermeldiung unerwünscht. was dann?
Ich bin gespannt, ob Sven uns vernünfig[tm] erklären kann, wie man substantiierte Fehlerbehandlung in PHP betreiben kann, ohne gleich die Kanone von try/catch aufzufahren und ohne lauter Texte auswerten zu müssen.
Da würde ich dann nämlich gerne zugeben, dass er mehr weiß als ich.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Moin!
Vernünftige Programmierer arbeiten ohne @.
manchmal überprüft man etwas mit einem if(), um eben den fehlerfall zu bearbeiten, allerdings wäre dann die zusätzliche fehlermeldiung unerwünscht. was dann?
Habe ein Beispiel, dann erkläre ich es dir gern.
Es entspricht meiner Erfahrung, dass PHP üblicherweise keine Fehler auswirft, nur weil irgendetwas geprüft werden muss. Jedes @ ist vermeidbar - wie genau, hängt von der Aufgabenstellung ab.
Ansonsten verweise ich auf die allgemein zugänglichen Methoden der Fehlermeldungsausgabeunterdrückung in meiner Antwort an Tom
- Sven Rautenberg
--
"Love your nation - respect the others."
-
-
Hallo,
Vernünftige Programmierer arbeiten ohne @.
aha, und wie stellst du z.B. sicher, dass man die mail() Funktion ohne Fehler abläuft, d.h. dass in der php.ini ein entsprechender SMTP Dienst eingetragen ist und dieser einwandfrei läuft.
Klar kann ich einen eigenen Error Handler basteln (oder Error Reporting ganz austellen), ist aber auch im Fall von Mail nicht unbedingt wünschenwert.Ich meine solch ein Fall:
if(@mail(...))
echo "Mail wurde gesendet";
else
echo "Leider konnte deine Mail nicht gesendet werden. Erreichen kannst du uns unter abc@efg.com";Wäre schön zu wissen, wie vernünftige Programmierer dieses ohne @ lösen.
Grüße
Klaus-
Hello,
Vernünftige Programmierer arbeiten ohne @.
aha, und wie stellst du z.B. sicher, dass man die mail() Funktion ohne Fehler abläuft, d.h. dass in der php.ini ein entsprechender SMTP Dienst eingetragen ist und dieser einwandfrei läuft.
Klar kann ich einen eigenen Error Handler basteln (oder Error Reporting ganz austellen), ist aber auch im Fall von Mail nicht unbedingt wünschenwert.Ich meine solch ein Fall:
if(@mail(...))
echo "Mail wurde gesendet";
else
echo "Leider konnte deine Mail nicht gesendet werden. Erreichen kannst du uns unter abc@efg.com";Wäre schön zu wissen, wie vernünftige Programmierer dieses ohne @ lösen.
Das Problem ist nicht, wie man die Konsolen-Fehlermeldung unterdrückt.
Dazu musst Du ja nur "display_errors" später auf off stellen und die Meldungen in ein Error_Log umleiten.Das Problem ist, wie man im Programm während der Laufzeit qualifizierte Fehlermeldungen erhält und diese dann auch auswerten kann, ohne erst dubiose Texte aus php_errmsg parsen zu müssen.
Darum kann eine wesentlich Frage nur lauten:
Gibt es eine Systemvariable, die passend zu php_errmsg einen eindeutigen Errorcode enthält?Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hello,
Gibt es eine Systemvariable, die passend zu php_errmsg einen eindeutigen Errorcode enthält?
Also zur Korrektur für die Nachwelt: Die Variable, die die letzte Fehlermeldung in textform enthält, heißt
$php_errormsg
und alles öffentliche zum Thema steht unter
http://www.php.net/manual/en/errorfunc.configuration.php
Aber dort finde ich keine vernünftige[tm] Variable für die Fehlerbehandlung.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo,
Gibt es eine Systemvariable, die passend zu php_errmsg einen eindeutigen Errorcode enthält?
Aber dort finde ich keine vernünftige[tm] Variable für die Fehlerbehandlung.
?? Dazu gibts Error Handler (error_get_last, set_error_handler ...). Die wurden doch schon genannt. Wo ist das Problem?
Mathias
-
Hello,
Aber dort finde ich keine vernünftige[tm] Variable für die Fehlerbehandlung.
?? Dazu gibts Error Handler (error_get_last, set_error_handler ...). Die wurden doch schon genannt. Wo ist das Problem?
Es ist Dir aber sicherlich nicht entgangen, dass das erst seit (PHP 5 >= 5.2.0) existiert?
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo
Aber dort finde ich keine vernünftige[tm] Variable für die Fehlerbehandlung.
?? Dazu gibts Error Handler (error_get_last, set_error_handler ...). Die wurden doch schon genannt. Wo ist das Problem?
Es ist Dir aber sicherlich nicht entgangen, dass das erst seit (PHP 5 >= 5.2.0) existiert?
Ist mir auch aufgefallen. Allerdings habe ich auch schon unter PHP 4 im systemeigenen Errorlog aussagekräftige Fehlermeldungen gehabt. Für einen eigenen Error Handler ist die Funktion aber Gold wert (wenn auch erst ab PHP 5.2).
Tschö, Auge
-
Hallo,
Aber dort finde ich keine vernünftige[tm] Variable für die Fehlerbehandlung.
?? Dazu gibts Error Handler (error_get_last, set_error_handler ...). Die wurden doch schon genannt. Wo ist das Problem?
Es ist Dir aber sicherlich nicht entgangen, dass das erst seit (PHP 5 >= 5.2.0) existiert?
set_error_handler() gibt's schon seit PHP 4.0.1 - und das sollte zum Abfangen (und z.B. zum Verhindern, dass sie angezeigt werden) von nicht-fatalen Fehlern vollkommen ausreichen.
Ferner: Jeder, der mit PHP < 5.2 unterwegs ist, ist heutzutage selbst Schuld. 5.0 und 5.1 haben etliche ungefixte Sicherheitslücken und 4.x wird nicht mehr supportet.
Viele Grüße,
Christian-
Hello,
Aber dort finde ich keine vernünftige[tm] Variable für die Fehlerbehandlung.
?? Dazu gibts Error Handler (error_get_last, set_error_handler ...). Die wurden doch schon genannt. Wo ist das Problem?
Es ist Dir aber sicherlich nicht entgangen, dass das erst seit (PHP 5 >= 5.2.0) existiert?
set_error_handler() gibt's schon seit PHP 4.0.1 - und das sollte zum Abfangen (und z.B. zum Verhindern, dass sie angezeigt werden) von nicht-fatalen Fehlern vollkommen ausreichen.
Leider reicht die numerische fehlermeldung für eine qualifizierte Behandlung von Laufzeitfehlern nicht aus. Die neue Funktion leistet leider nicht mehr, als es schon set_error_handler() nebst eigener Auswertefunktion getan hat. Aber sad müsstest Du wissen, wenn Du dich wirklich damit beschäftigt hättest!
Informationen, die über set_error_handler() erhältlich sind:
Error-Nr: 2
Error-String: fopen(unbekannt.txt) [function.fopen]: failed to open stream: Permission denied
Error-String: C:\Programme\xampp\htdocs\test\error_msg\error.php
Error-String: 18Konsolen-Fehlermeldung:
Warning: fopen(unbekannt.txt) [function.fopen]: failed to open stream: Permission denied in C:\Programme\xampp\htdocs\test\error_msg\error.php on line 18
Rückgabewerte von error_get_last():
Array
(
[type] => 2
[message] => fopen(unbekannt.txt) [<a href='function.fopen'>function.fopen</a>]: failed to open stream: Permission denied
[file] => C:\Programme\xampp\htdocs\test\error_msg\error.php
[line] => 18
)Grüße an Dich und den Rest der Welt aus Syburg bei Dortmund
Tom vom Berg
-
Hallo,
Aber sad müsstest Du wissen, wenn Du dich wirklich damit beschäftigt hättest!
Don't make him sad!
Mathias
-
Hello,
Aber sad müsstest Du wissen, wenn Du dich wirklich damit beschäftigt hättest!
Don't make him sad!
Gut gebrüllt Löwe!
Mir geht es doch auch nur um die Sache mit mit den Fehlernummern in PHP und nicht darum, dem liben Christian Kummer zu bereiten. Den bereitet er sich immer nur selber, weil er mich für blöder hält, als ich mich anstelle :-)
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo,
Mir geht es doch auch nur um die Sache mit mit den Fehlernummern in PHP und nicht darum, dem liben Christian Kummer zu bereiten.
Der Gute heißt Christoph Kummer und hat mit Libs nichts zu tun. ;)
Mathias
-
Hello,
Mir geht es doch auch nur um die Sache mit mit den Fehlernummern in PHP und nicht darum, dem lieben Christian Kummer zu bereiten.
Der Gute heißt Christoph Kummer und hat mit Libs nichts zu tun. ;)
Christoph Kummer hat mir gerade kürlich noch versichert, dass er hier zwar gelegentlich mitliest, aber bestimmt nicht so schnell mitposten wird. Ich habe ihn hier auch noch nicht gelesen die letzten Tage.
Aber trotzdem ein netter Versuch, für Auflockerung zu sorgen. :-)
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
-
-
Hallo,
Leider reicht die numerische fehlermeldung für eine qualifizierte Behandlung von Laufzeitfehlern nicht aus.
Dass Du keinen vollwertigen Fehlercode aus PHP herausbekommst, war mir auch klar, ich ging lediglich darauf ein, dass error_get_last() eben erst ab 5.2 zur Verfügung steht und habe erläutert, warum man in vorigen PHP-Versionen auch ohne ausgekommen ist.
Dass gerade bei I/O ein vollwertiger Fehlercode extrem hilfreich wäre (und andere Sprachen setzen das ja auch um, Python und Java z.B. mit Exceptions), bestreite ich ja gar nicht. Nur den bekommst Du auch in PHP 5.2 nicht.
Viele Grüße,
Christian-
Hello,
Leider reicht die numerische fehlermeldung für eine qualifizierte Behandlung von Laufzeitfehlern nicht aus.
Dass Du keinen vollwertigen Fehlercode aus PHP herausbekommst, war mir auch klar, ich ging lediglich darauf ein, dass error_get_last() eben erst ab 5.2 zur Verfügung steht und habe erläutert, warum man in vorigen PHP-Versionen auch ohne ausgekommen ist.
Dass gerade bei I/O ein vollwertiger Fehlercode extrem hilfreich wäre (und andere Sprachen setzen das ja auch um, Python und Java z.B. mit Exceptions), bestreite ich ja gar nicht. Nur den bekommst Du auch in PHP 5.2 nicht.
Ok, dann will ich hierzu eine letzte Frage stellen, die Du vielleicht beantworten kannst:
Was könnte man denn tun, die PHP-Entwickler dazu zu bewegen, diese augenscheinliche Schwachstelle auszubügeln? Wo müsste man denn da vorstellig werden und vor allem, welche Sprachregelungen gelten dort?Aus eigener Erfahrung weiß ich, die lassen sich nicht so einfach etwas vorschlagen. Man bekommt ziemlich dämliche Antworten zurück, wenn überhgaupt. In der Sache haben sie dann damals aber trotzdem ganz leise und heimlich reagiert :-|
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo Tom,
Ok, dann will ich hierzu eine letzte Frage stellen, die Du vielleicht beantworten kannst:
Was könnte man denn tun, die PHP-Entwickler dazu zu bewegen, diese augenscheinliche Schwachstelle auszubügeln?Denke Dir ein brauchbares Konzept aus, das folgende Bedingungen erfüllt:
1) Es bricht keine Kompabilität mit bisherigen Anwendungen.
2) Es ist sinnvoll für andere Zwecke erweiterbar (es gibt ja nicht nur
Fehler im I/O-Bereich).
3) Es weicht nicht zu stark von bisher in PHP vorhandenen Konzepten ab.
(Schau Dir dazu insbesondere Streams mal genauer an)Und schlage das dann auf der Mailingliste internals@lists.php.net vor (auf Englisch).
Ich würde denken, dass vor allem der Punkt 1) rein konzeptionell große Probleme bereiten dürfte. Viel Spaß beim Grübeln.
Viele Grüße,
Christian
-
-
-
-
-
Hallo,
Es ist Dir aber sicherlich nicht entgangen, dass das erst seit (PHP 5 >= 5.2.0) existiert?
In Anknüpfung an Christian:
Vernünftige Fehlerbehandlung unter PHP < 5.2 wäre ein PHP-Upgrade. ;)Mathias
-
Hello,
Es ist Dir aber sicherlich nicht entgangen, dass das erst seit (PHP 5 >= 5.2.0) existiert?
In Anknüpfung an Christian:
Vernünftige Fehlerbehandlung unter PHP < 5.2 wäre ein PHP-Upgrade. ;)Nur weil Du es wiederholst, wird es nicht besser:
PHP 5.2.0 liefert mMn keine besseren Fehlermeldungen, als es bereits PHP 4.x tat. Es liefert sie nur in einer vereinfachten Weise. Die Qualifizierten Fehlernummern ähnlich errno in C/C++ fehlen immer noch und das, obwohl die Fehlertexte in $php_errormsg die gewünschte Information enthalten. Es ist aber unsinn, vom Runtime einen text erzeugen zu lassen (dessen Sprache noch nicht einmal abgesichert ist), um ihn im Programm dann wieder vergleichen zu lassen, um seine Schlüsse daraus ziehen zu können.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
-
-
-
-
Moin!
Vernünftige Programmierer arbeiten ohne @.
aha, und wie stellst du z.B. sicher, dass man die mail() Funktion ohne Fehler abläuft, d.h. dass in der php.ini ein entsprechender SMTP Dienst eingetragen ist und dieser einwandfrei läuft.Das Zurverfügungstellen einer funktionsfähigen Infrastruktur ist Aufgabe des Server-Administrators. Dazu gehört auch der Mailversand per Skript.
Wollte man die PHP-seitige Konfiguration prüfen, würde ich auf ini_get() zurückgreifen - die einschlägigen Konfigurationsoptionen sind ja nicht so zahlreich, dass das in Arbeit ausarten würde.
Aber gerade das mail()-Kommando ist das mit Abstand ekligste in ganz PHP - was primär aber daran liegt, dass EMail einfach nur als unzuverlässig zu betrachten ist, zumindest wenn man den "Erfolg" am Rückgabewert "true" oder "false" ermittelt.
Eine deutlich schönere Methode, Mails zu versenden, wäre beispielsweise mit PEAR Mail.
Klar kann ich einen eigenen Error Handler basteln (oder Error Reporting ganz austellen), ist aber auch im Fall von Mail nicht unbedingt wünschenwert.
Ich meine solch ein Fall:
if(@mail(...))
echo "Mail wurde gesendet";
else
echo "Leider konnte deine Mail nicht gesendet werden. Erreichen kannst du uns unter abc@efg.com";Wäre schön zu wissen, wie vernünftige Programmierer dieses ohne @ lösen.
Dein Beispiel geht davon aus, dass ungewiß ist, ob der benutzte Server den Mailversand konfiguriert bekommen hat. Das halte ich für wenig wahrscheinlich. Mailversand ist in der Regel konfiguriert. Und sollte er nicht funktionieren, äußert sich das dummerweise nur in seltenen Fällen durch den Rückgabewert "false" der Mailfunktion.
Aber dein "Ersatzszenario" im Mißerfolgsfall ist ja auch alles andere als äquivalent. Es gibt einfach Mails, die man bei Nichtversand nicht einfach dem Benutzer zur freien Formulierung zurückgeben kann, sondern die programmgeneriert verschickt werden muss.
- Sven Rautenberg
--
"Love your nation - respect the others."
-
-
-
