Pourquoi les blocs de capture vides sont-ils une mauvaise idée ?

Question

Je viens de voir un question sur le try-catch Quelles sont les personnes (y compris Jon Skeet) qui disent que les blocs de capture vides sont une très mauvaise idée ? Pourquoi cela ? N'y a-t-il aucune situation où un bloc de capture vide n'est pas une mauvaise décision de conception ?

Je veux dire, par exemple, que parfois vous voulez obtenir des informations supplémentaires de quelque part (service web, base de données) et vous ne vous souciez pas vraiment de savoir si vous obtiendrez ces informations ou non. Vous essayez donc de l'obtenir, et si quelque chose se passe, c'est bon, je vais juste ajouter un "catch (Exception ignored) {}" et c'est tout.

Answer 1

En général, les try-catchs vides sont une mauvaise idée car ils permettent d'avaler silencieusement une condition d'erreur et de poursuivre l'exécution. Occasionnellement, cela peut être la bonne chose à faire, mais souvent c'est un signe qu'un développeur a vu une exception, ne savait pas quoi faire à ce sujet, et a donc utilisé un catch vide pour faire taire le problème.

C'est l'équivalent en programmation de mettre du ruban adhésif noir sur un voyant de moteur.

Je pense que la façon dont vous traitez les exceptions dépend de la couche du logiciel dans laquelle vous travaillez : Exceptions dans la forêt tropicale .

Answer 2

C'est une mauvaise idée. en général parce qu'il s'agit d'une condition vraiment rare où un échec (condition exceptionnelle, de manière plus générale) est correctement traité sans aucune réponse. En plus de cela, le vide catch Les blocs sont un outil commun utilisé par les personnes qui utilisent le moteur d'exception pour le contrôle d'erreur qu'ils devraient faire de manière préemptive.

Pour dire que c'est siempre mauvais est faux... c'est vrai pour très peu de choses. Il peut y avoir des circonstances où soit vous ne vous souciez pas de l'erreur, soit la présence de l'erreur indique d'une manière ou d'une autre que vous ne pouvez rien y faire de toute façon (par exemple, lorsque vous écrivez une erreur précédente dans un fichier journal textuel et que vous obtenez un message de type IOException (ce qui signifie que vous ne pourriez pas écrire la nouvelle erreur de toute façon).

Answer 3

Je n'irais pas jusqu'à dire que celui qui utilise des blocs catch vides est un mauvais programmeur et ne sait pas ce qu'il fait...

J'utilise des blocs de capture vides si nécessaire. Parfois, le programmeur de la bibliothèque que je consomme ne sait pas ce qu'il fait et lance des exceptions même dans des situations où personne n'en a besoin.

Par exemple, considérons une bibliothèque de serveur http, je ne pourrais pas me soucier moins que le serveur lève une exception parce que le client s'est déconnecté et index.html n'a pas pu être envoyé.

Answer 4

Je pense que c'est bon si tu attrapes un particulier un type d'exception dont vous savez qu'elle ne sera levée que pour une seule particulier Vous vous attendez à cette exception et n'avez pas besoin de faire quoi que ce soit.

Mais même dans ce cas, un message de débogage peut s'avérer utile.

Answer 5

Les exceptions ne doivent être levées que s'il s'agit réellement d'une exception, c'est-à-dire d'un événement hors norme. Un bloc catch vide dit en gros "quelque chose de grave est en train de se produire, mais je m'en fiche". C'est une mauvaise idée.

Si vous ne voulez pas gérer l'exception, laissez-la se propager vers le haut jusqu'à ce qu'elle atteigne un code qui puisse la gérer. Si rien ne peut gérer l'exception, l'application devrait être arrêtée.