nicht angemeldet
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:
- Ich kann den Rückgabewert einer Funktion auswerten und mit weiterführenden API-Funktionen Informationen über den Fehler sammeln.
- 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