Error unterdrückung

[MB.]

nabend,

wozu dient der @-Operator vor Funktionen? wenn ich keinen Error haben will, dann schalte ich einfach von E_ALL nach 0 oder NULL. Oder ist das von der Programmiersturuktur her zu empfehler wenn man das @ von einer Funktion trotzdem setzt, damit größere Fehler schneller lokalisiert werden. Natürlich Voraus gesetzt zur Entwicklung und Debuggen zwecken, wenn man error_report( E_ALL ) setzt

Grüße MB

[Jörg Reinholz]

Moin!

wozu dient der @-Operator vor Funktionen?

Ja, der "@-Operator" ist eine eher zweifelhafte Erfindung und sollte gemieden werden.

Wenn z.B. eine Datei nicht da ist und halt neu geschrieben werden soll, dann kann man statt

@$fh=fopen($DateiName,'r+');

besser mit:

• is_file ( $DateiName )
• is_readable ( $DateiName )
• is_writable ( $DateiName ) (SIC! Auch für das Verzeichnis!)

prüfen und die Datei ggf. mit touch ( $DateiName ) anlegen. Auch Fehlermeldungen kann man entsprechend genauer als mit einem "Geht nicht!" (welches wir ja auch hier im Forum so "sehr" lieben...) gestalten. Bleibt noch try ... catch als bessere Lösung.

Jörg Reinholz

[1unitedpower]

Wenn z.B. eine Datei nicht da ist und halt neu geschrieben werden soll, dann kann man statt […]

Wieso statt? Das was du hier zeigst schließt die Verwendung des @-Operators ja nicht aus. Ich kann all diese Laufzeit-Abfragen machen und trotzdem an entscheidener Stelle den @-Operator verwenden, um die Datei zu lesen. Die Verwendung des Operators macht sich erst dann bemerkbar, wenn ich keine proaktive sondern nur reaktive Fehlerbehandlung betreiben kann. Bei der reaktiven Fehlerbehandlung habe ich in PHP oft nur zwei Möglichkeiten:

1. Ich kann den Rückgabewert einer Funktion auswerten und mit weiterführenden API-Funktionen Informationen über den Fehler sammeln.
2. Ich kann das Exception-System mit try-catch nutzen.

Bei Verwendung von PDO::commit kann ich bswp. den Rückgabewert auswerten und im Fehlerfall mit PDO::errorCode und PDO::errorInfo weitere Details abfragen um auf den Fehler zu reagieren. Diese erste Variante funktioniert immer, auch wenn der @-Operator benutzt wird. Interessant ist deshalb vor allem der zweite Fall: Denn mit dem @-Operator kann ich vermeiden, dass eine Exception geworfen wird und damit unterbinde ich ggf. auch das Betreten eines catch-Blockes. Die Kombination try-catch und @-Operator ist also eher ungünstig. Wichtig ist, dass die Entscheidung ob man eine reaktive Fehlerbehandlung nach Methode 1 oder 2 betreibt häufig nicht beim Anwendungs-Programmierer liegt, sondern von der API vorgegeben wird.

Der @-Operator wird häufig dafür kritisiert, dass er das Debugging erschwert. Dieses Argument ist heute aber wegen hochentwickelter Debugger auch nicht mehr so stark, wie es ein Mal gewesen sein mag. Mit xdebug habe ich zum Beispiel die Möglichkeit die Wirkung des @-Operators zu unterdrücken.

[Der Martin]

Hallo,

wozu dient der @-Operator vor Funktionen?

zum Unterdrücken von Fehlermeldungen, obwohl man sie unterschwellig erwartet und Maßnahmen trifft, die Fehler selbst abzufragen und darauf zu reagieren, anstatt sie in der HTML-Ausgabe zu haben.

wenn ich keinen Error haben will, dann schalte ich einfach von E_ALL nach 0 oder NULL. Oder ist das von der Programmiersturuktur her zu empfehler wenn man das @ von einer Funktion trotzdem setzt, damit größere Fehler schneller lokalisiert werden. Natürlich Voraus gesetzt zur Entwicklung und Debuggen zwecken, wenn man error_report( E_ALL ) setzt

Der wesentliche Unterschied ist, dass der @-Operator nur punktuell an der Stelle wirkt, wo er steht. Wenn man das error_reporting ändert, wirkt sich das aber auf das gesamte Script aus.

So long,
 Martin

[dedlfix]

Tach!

wozu dient der @-Operator vor Funktionen? wenn ich keinen Error haben will, dann schalte ich einfach von E_ALL nach 0 oder NULL.

Das @ macht genau das, es braucht dazu aber nur das eine Zeichen und keine zwei Zeilen zum aus- und wieder anschalten.

Oder ist das von der Programmiersturuktur her zu empfehler wenn man das @ von einer Funktion trotzdem setzt, damit größere Fehler schneller lokalisiert werden.

Mit dem @ kann man keine Fehler lokalisieren. Man kann nur die Meldungen unterdrücken. Das nimmt man dann, wenn man genau weiß, dass man an der Stelle Meldungen bekommt, die Ursache aber bekannt ist und anderweitig Berücksichtigung findet.

Natürlich Voraus gesetzt zur Entwicklung und Debuggen zwecken, wenn man error_report( E_ALL ) setzt

Bei einem @ hat ein E_ALL keinen Einfluss. Das error_reporting kann irgendwie stehen, es wird ja sowieso vom @ auf 0 gesetzt.

dedlfix.

[Regina Schlaukrug]

Mit dem @ kann man keine Fehler lokalisieren. Man kann nur die Meldungen unterdrücken. Das nimmt man dann, wenn man genau weiß, dass man an der Stelle Meldungen bekommt, die Ursache aber bekannt ist

Diese dämliche Begründung scheint sehr beliebt zu sein.

Es wird ein Kredit ins Auge gefasst, man weiss genau, dass man ihn nicht zurückzahlen kann, aber anstatt die Ursache für das Geldproblem korrekt zu behandeln, wird der Kredit aufgenommen und die unweigerlich folgendenden Mahnungen der Bank ungeöffnet in die Tonne gedrückt.

[dedlfix]

Tach!

Mit dem @ kann man keine Fehler lokalisieren. Man kann nur die Meldungen unterdrücken. Das nimmt man dann, wenn man genau weiß, dass man an der Stelle Meldungen bekommt, die Ursache aber bekannt ist

Diese dämliche Begründung scheint sehr beliebt zu sein.

Es wird ein Kredit ins Auge gefasst, man weiss genau, dass man ihn nicht zurückzahlen kann, aber anstatt die Ursache für das Geldproblem korrekt zu behandeln, wird der Kredit aufgenommen und die unweigerlich folgendenden Mahnungen der Bank ungeöffnet in die Tonne gedrückt.

Du hast mein Argument nicht verstanden oder den Teil "die Ursache aber bekannt ist" überlesen. Ich sagte nicht, dass man Fehlermeldungen um jeden Preis unterdrücken soll. Es geht mir darum, um bei deinem Beispiel zu bleiben, dass man ganz genau weiß, dass man den Kredit zurückzahlt, nur eben nicht auf den Mahnbrief hin, sondern selbstbestimmt auf eine besser passende Weise oder einem besser passenden Zeitpunkt.

Bei mir kann ich mich an einen Einsatz nur an getimagesize() erinnern. Damals gab es Fileinfo noch nicht (im Standard-Lieferumfang von PHP), mit dem man Dateitypen ermitteln konnte. Man kann getimagesize() jedoch auch auf Nichtgrafiken (hochgeladene beispielsweise) anwenden und bekommt so raus, ob es sich nicht um eine Grafik handelt, wenn das Ergebnis false ist. (Dazu verweist das Handbuch heutzutage auf besagtes Fileinfo.) Dummerweise hat diese Funktion dann aber auch eine Warnung ausgegeben. "Ja, liebes PHP, ich weiß, dass das keine Grafik ist. Ich erkenne das an deinem Rückgabewert, den ich auswerte. Du musst mir das nicht nochmal extra erzählen." Diese Warnung ist anscheinend Geschichte, denn beim Probieren eben kam sie nicht mehr.

Solche Situationen meine ich, in denen man aktive Fehlerbehandlung betreibt und eine Meldung in der Ausgabe oder im Logfile mehr stört als nützt. Das Unterdrücken ohne adäquate Eigenbehandlung bekommt von mir keine Empfehlung.

dedlfix.