L'erreur supprime-t-elle les mauvaises pratiques?

Sur une question SO que j'ai posée ici à propos d'un code dont je n'étais pas sûr, quelqu'un a répondu "BTW, code horrible là-bas: il utilise beaucoup le symbole de suppression d'erreur (@)."

Y a-t-il une raison pour laquelle c'est une mauvaise pratique? Avec des choses comme:

$db=@new mysqli($db_info) or die('Database error');

, cela me permet d'afficher uniquement un message d'erreur personnalisé. Sans suppression d'erreur, il afficherait toujours le message PHP typique de:

Avertissement : mysqli :: mysqli (): php_network_getaddresses: échec de getaddrinfo: aucun hôte de ce type n'est connu. dans un \ file \ path sur la ligne 6

ainsi que «Erreur de base de données».

La suppression des erreurs est-elle toujours mauvaise et, dans l'affirmative, qu'est-ce qui est spécifiquement mauvais dans ce qui précède?

Mise à jour: le code réel que j'utilise est:

or error('Datatabase error', 'An error occurred with the database' . (($debug_mode) ? '<br />MySQL reported: <b>' . $db->error . '</b><br />Error occurred on line <b>' . __LINE__ . '</b> of <b>' . __FILE__ . '</b>' : ''))

qui supprime toutes les sorties précédentes et affiche un message d'erreur. Par conséquent, le fait que le message d'erreur ne contienne pas de détails sur ce qui s'est spécifiquement produit (ce que les gens semblent suggérer comme une raison pour laquelle la suppression des erreurs est mauvaise) n'est pas pertinent.

Je pense que vous faites la bonne chose en supprimant l'erreur, car vous implémentez votre propre gestion des erreurs.

Il pourrait être plus facile de considérer l'équivalent, par exemple, en Java. La suppression de l'erreur en utilisant @est analogue à la déglutition d'une exception. Le code suivant, similaire au vôtre, est raisonnable:

try {
    db = new MySQLi(dbInfo);
} catch (SQLException connectionFailure) {
    die("Database error");
}

(Eh bien, en Java, vous ne voudriez pas que le moteur de servlet meure, mais vous avez compris.)

Cependant, ce n'est pas acceptable:

try {
    db = new MySQLi(dbInfo);
} catch (Exception e) {
}

La plupart des suppressions d'erreurs PHP se font négligemment, comme dans ce dernier exemple, d'où la réaction instinctive contre votre code.

La suppression des erreurs est mauvaise, car elle ne masque pas seulement les informations que vous connaissez déjà ( quelque chose s'est mal passé). Il peut également masquer des informations vitales pour le débogage dont vous n'êtes pas au courant ( quoi , où et pourquoi ).

Dans cet exemple spécifique, « Erreur de base de données » n'est pas un très bon message d'erreur. Quelque chose s'est mal passé avec la DB. Pas très instructif. Le message " Avertissement: mysqli :: mysqli (): php_network_getaddresses: getaddrinfo a échoué: aucun hôte de ce type n'est connu. dans certains \ file \ path sur la ligne 6 "est en fait un meilleur message d'erreur. Il vous donne un emplacement et une raison pour le problème. Vous pouvez sauter directement et commencer le débogage, car l'erreur a déjà été localisée.

Bien sûr, les concepteurs de bibliothèques ont parfois tendance à afficher de nombreux avertissements non pertinents. Je ne connais pas suffisamment PHP pour savoir s'il a un moyen de filtrer les avertissements qui ne vous intéressent pas. Je sais que la lecture d'une trace de pile de cent lignes n'est pas très éclairante. Mais la réponse correcte à trop d'informations n'est pas de réduire la quantité d'informations à zéro , mais de filtrer les parties non pertinentes à un moment donné. L' @opérateur n'a pas cette granularité (sa devise est tout ou rien ), et n'est donc pas un outil approprié pour une gestion efficace des erreurs.

Il y a des cas où vous savez qu'une certaine erreur se produira et que la résolution du problème réel est plus coûteuse que la réduction au silence du message (et la souffrance potentielle de cela). Cela pourrait être le cas dans un script unique, mais enfoncer vos doigts dans vos oreilles et faire « la la la » n'est pas une réponse professionnelle aux bugs (potentiels).

La suppression des erreurs est mauvaise car elle cache le problème, dont nous ne sommes même pas souvent conscients et cela peut entraîner un comportement inattendu qui peut s'avérer très coûteux dans certaines applications critiques, par exemple dans les applications utilisées dans les domaines financier, de la santé et de la défense.

Ce n'est également pas une bonne idée d'avoir des exceptions non gérées dans le code et d'afficher les messages d'erreur réels à l'utilisateur car cela peut entraîner des problèmes de sécurité car les messages d'erreur révèlent généralement beaucoup de choses sur votre code, ce qui peut aider les utilisateurs malveillants et les pirates à manipuler le système.

Ainsi, la bonne pratique consiste à gérer les erreurs à différents niveaux, par exemple au niveau le plus élevé, vous pouvez gérer l'erreur en enregistrant simplement l'erreur réelle et en affichant un message simple et convivial à l'utilisateur.

Oui, l'opérateur de suppression d'erreur est généralement une mauvaise idée.

Vous devez gérer les rapports d'erreurs dans la configuration ( php.ini). Vous pouvez donc choisir un paramètre différent pour chaque environnement (par exemple, laisser des avertissements en développement et les masquer en production).

La seule situation où l'utilisation @pourrait avoir un sens est lorsque vous développez une bibliothèque pour d'autres développeurs. Si vous choisissez volontairement de faire quelque chose qui génère un avertissement et que vous ne voulez pas ennuyer les utilisateurs de votre bibliothèque avec un avertissement qui ne dépend pas d'eux, cela @pourrait être une solution.

Je ne pense à aucune autre utilisation.