Comme nous l'avons vu, lorsque qu'une erreur se déclenche en PHP le gestionnaire d'erreur effectue trois opérations :
- enregistrement de l'erreur dans le journal
- affiche de l'erreur en sortie
- arrêt du script selon le niveau d'erreur
Ainsi que je l'ai déjà dit il y a fort longtemps : si sur un serveur de développement il est très intéressant de voir une erreur s'afficher en sortie dès lors qu'elle se déclenche ce n'est pas du tout le cas lorsque l'on utilise sont script sur un serveur de production.
A l'inverse lorsque l'on est en train d'écrire et/ou de tester son script il est totalement inutile d'enregistrer dans un journal les erreurs potentielles, alors que ca l'est une fois le service en ligne. En effet il est très intéressant de pouvoir être prévu si des erreurs ont été oublié dans la phase de développement.
Le problème avec l'opérateur @, c'est qu'il désactive complétement la gestion des erreurs de PHP. Qu'il s'agisse de leur affichage mais également de leur enregistrement au journal.
Utiliser l'opérateur de contrôle d'erreur @ pour masquer l'affichage d'une erreur est une mauvaise pratique car cela empêche à la fois de connaître l'existence d'un comportement inattendu mais également de le traiter efficacement !
Conclusion
Dans la phase de développement de votre script, n'ignorez pas vos messages d'erreur : traitez les erreurs à la source dès lors qu'elles se produisent. Ou même mieux, en évités les en amont.
A l'inverse dans un cadre de production n'affichez pas vos erreurs mais pensez à bien les enregistrer pour mieux connaître et appréhender les faiblesses de votre script.
De plus tout bon administrateur système vous dira que les journaux sont de bonnes sources d'informations en cas de panne ou de piratage. Si vous utilisez l'opérateur @ de PHP vous perdez toute chance de pouvoir jouir d'une telle information.