Meine Herren!

Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die Ausgabe der Meldung unterdrücken

Ja sollte ich eine eigene Fehlerbehandlung betreiben?

Wenn dir kein akuter Grund vorliegt, dann nicht. Im schlimmsten Fall schadet man sich selbst damit mehr als man gut machen kann.

Und wenn doch, dann sollte man on-top etwas bauen und nicht gegen die bestehenden Sicherheitsmechanismen arbeiten.

Der @-Operator ist ein Parade-Beispiel. Man unterdrückt damit nämlich nicht nur die Fehlermeldung, sondern auch die Fehler-Berichterstattung. Das heißt es wird nicht nur die Frontend-Ausgabe des Fehlers unterdrückt, sondern zum Beispiel auch das Logging des Fehlers. Der eigene Custom-Handler wird zwar trotzdem aufgerufen, aber das Logging ist verloren.

Auch mit try/catch kann man sich sehr schnell in eine Sackgasse manövrieren. In fast 100% der Fälle sehe ich folgendes Konstrukt:

try { … } catch ( Exception $e ) { … }

Das Problem mit diesem Code ist, dass er einfach jede Exception abfängt und nicht nur spezifische Subclassen von Exception. In den meisten Fällen bezieht sich so ein try-Block nämlich auf ein paar wenige Zeilen, die ganz konkrete Fehler werfen, imho. sollte man sich dann im Catch-Block auch genau darauf beziehen.

Bevor man anfängt willkürlich irgendwelche Custom-Error-Handler zu registrieren, sollte man sich erstmal mit den bestehenden Möglichkeiten auseinander setzen und meiner Meinung nach sollte man immer auf das bewährte und erprobte native Fehlersystem setzen, wenn es geht. Nur wenn dann noch Wünsche offen bleiben, sollte man sich Gedanken um eine Erweiterung machen. Das wäre zum Beispiel der Fall, wenn man bei bestimmten kritischen Fehlern eine Email erhalten möchte. Dafür gibt es in PHP keine Standard-Direktive, da würde sich eine eigene Behandlungs-Routine lohnen.