Pourquoi exceptions doivent être utilisées avec prudence ?

Question

Double Possible:
Pourquoi la gestion des exceptions mauvais?

J'ai souvent voir/entendre des gens dire que les exceptions ne devraient être utilisées que rarement, mais jamais expliquer pourquoi. Tout cela peut être vrai, la raison d'être est normalement un glib: "cela s'appelle une exception pour une raison" qui, pour moi, semble être le genre d'explication qui ne devrait jamais être accepté par un respectable programmeur/ingénieur.

Il existe toute une gamme de problèmes qu'une exception peut être utilisé pour résoudre. Pourquoi est-il déconseillé de l'utiliser pour le contrôle de flux? Quelle est la philosophie derrière très prudent avec la façon dont ils sont utilisés? La sémantique? La Performance? La complexité? L'esthétique? Convention?

J'ai vu des analyses sur la performance avant, mais à un niveau qui serait pertinent pour certains systèmes et sans intérêt pour les autres.

Encore une fois, je ne suis pas nécessairement en désaccord qu'ils doivent être enregistrés pour des circonstances particulières, mais je me demandais ce que le consensus justification (si une telle chose existe).

Answer 1

1. Cher
   noyau d'appels (ou d'autres API de système d'invocations) pour gérer noyau (système) signal d'interfaces
2. Difficile à analyser
   De nombreux problèmes de l' goto déclaration s'appliquent à des exceptions. Ils sautent sur potentiellement de grandes quantités de code souvent dans plusieurs routines et les fichiers source. Ce n'est pas toujours évident, à la lecture de la source intermédiaire de code. (Il est en Java.)
3. Pas toujours prévu par le code intermédiaire
   Le code a sauté par-dessus peuvent ou peuvent ne pas avoir été écrit avec la possibilité d'une exception à la sortie de l'esprit. Si à l'origine, de manière écrite, il peut ne pas avoir été maintenu avec cela à l'esprit. Pense: les fuites de mémoire, descripteur de fichier, les fuites de la prise de fuites, qui sait?
4. L'entretien des complications
   Il est plus difficile de maintenir le code qui saute autour de traitement des exceptions.

Answer 2

Lever une exception, qui est, dans une certaine mesure, similaire à une instruction goto. Que faire pour le contrôle de flux, et vous finissez avec le code spaghetti incompréhensible. Pire encore, dans certains cas, que vous ne savez pas encore où exactement le saut va (c'est-à-dire si vous n’êtes pas intercepter l’exception dans le contexte donné). Manifestement, cela viole le principe de « moins surprise » qui améliore la maintenabilité.

Answer 3

Les Exceptions font qu'il est plus difficile de raisonner sur l'état de votre programme. En C++, par exemple, que vous avez à faire réflexion supplémentaire pour assurer vos fonctions sont fortement exception sûr, que vous devez avoir à faire si ils n'ont pas besoin de l'être.

La raison en est que, sans exceptions, un appel de fonction peut renvoyer, ou il peut mettre fin au programme de première. Avec des exceptions, un appel de fonction peut renvoyer, ou il peut mettre fin au programme, ou il peut sauter d'un bloc catch quelque part. De sorte que vous pouvez ne plus suivre le flux de contrôle juste en regardant le code en face de vous. Vous avez besoin de savoir si les fonctions appelées pouvez jeter. Vous devez savoir ce qui peut être jeté et où il est pris, selon que vous vous souciez où le contrôle se passe, ou ne se soucient que cela laisse le champ d'application actuel.

Pour cette raison, les gens disent "ne pas utiliser les exceptions à moins que la situation est vraiment exceptionnel". Lorsque vous descendez à elle, "vraiment exceptionnel" signifie "un peu de situation a eu lieu là où les avantages de la manipulation avec une erreur de valeur de retour sont compensés par les coûts". Donc oui, c'est quelque chose d'une instruction vide, bien qu'une fois que vous avez quelques instincts de "vraiment exceptionnel", il devient une bonne règle de base. Quand les gens parlent de contrôle de flux, cela signifie que la capacité de raisonner localement (sans référence à des blocs catch) est une prestation de valeurs de retour.

Java a une définition plus large de "vraiment exceptionnel" qu'en C++. Les programmeurs C++ sont plus susceptibles de vouloir regarder la valeur de retour d'une fonction que les programmeurs Java, donc en Java "vraiment exceptionnel de" peut signifier "je ne peux pas retourner un objet non-null comme le résultat de cette fonction". En C++, il est plus susceptible de dire "je doute de ma appelant peut continuer". Ainsi, un Java flux jette si il ne peut pas lire un fichier, alors que C++ flux (par défaut) renvoie une valeur indiquant l'erreur. Dans tous les cas, cependant, c'est une question de ce code, vous êtes prêt à la force de votre appelant à écrire. C'est donc bien une question de style de codage: vous devez atteindre un consensus à ce que votre code devrait ressembler, et combien la "vérification des erreurs" code que vous voulez écrire contre combien "l'exception de sécurité" raisonnement que vous voulez faire.

Le large consensus sur l'ensemble des langues semble être que c'est mieux de le faire en termes de la façon dont recouvrable l'erreur est susceptible de l'être (car des erreurs irrécupérables résultat en aucun code avec des exceptions, mais encore besoin d'un check-et-retour-de-votre-propre-erreur dans le code qui utilise l'erreur renvoie). Donc, les gens attendent cette fonction m'appel déclenche une exception" pour dire "je ne peux pas continuer", pas juste "il ne peut pas continuer". Ce n'est pas inhérente dans les exceptions, c'est juste une coutume, mais comme tout bon en programmation, il est une coutume préconisée par les gens intelligents qui l'ai essayé dans l'autre sens et pas apprécié les résultats. Moi aussi, j'ai eu de mauvaises expériences jeter trop d'exceptions. Alors, personnellement, je ne pense qu'en termes de "vraiment exceptionnel", à moins que quelque chose au sujet de la situation de fait une exception particulièrement attractif.

Btw, indépendamment de raisonnement sur l'état de votre code, il y a aussi des implications sur les performances. Les Exceptions sont généralement à bas prix maintenant, dans les langues où vous êtes en droit de recevoir des soins sur la performance. Ils peuvent être plus rapides que plusieurs niveaux de "oh, le résultat est une erreur, je ferais mieux de sortir de moi-même avec une erreur de trop, alors". Dans les mauvais jours, il existe de réelles craintes que de jeter une exception, l'attraper, et continuer avec la prochaine chose, serait de faire ce que vous faites si lent que d'être inutile. Donc, dans ce cas, "vraiment exceptionnel", "la situation est tellement mauvaise que d'horribles performance n'a plus d'importance". Ce n'est plus le cas (bien qu'une exception dans une boucle serrée, est encore perceptible) et, espérons-indique en quoi la définition de "vraiment exceptionnel" doit être flexible.