est-il préférable d'éviter une exception avec une clause de garde ou de prendre l'exception? Il y a une meilleure pratique? Pro et inconvénients des deux méthodologies?
Par exemple, c'est mieux ceci: ou ceci: Merci à tous pour les réponses :)
4 Réponses :
Utiliser une clause de garde - attraper l'exception entraîne un coût d'exécution élevé et d'améliorer la lisibilité, vous ne devez utiliser que des exceptions pour les conditions d'erreur, pas pour le flux de contrôle normal
C'est une condition d'erreur ..Si il attend quelque chose à l'index 3, c'est une erreur s'il n'y a pas là-bas, il est préférable de fermer l'application et de loger cette erreur ..
@Anirudh cela dépend de la situation; peut corriger. Cela dépend de la question de savoir si la matrice ne peut pas avoir de nombreuses valeurs ou si l'application dépendait complètement du tableau étant au moins aussi grand. Cela détermine si vous devriez vérifier cela ou simplement le laisser jeter une exception.
@anirudha Je suis curieux pourquoi vous continuez à dire fermer l'application sur ce type d'exception? L'opération peut être réessayable ou pas suffisamment sévère pour justifier de fermer l'application. Pourquoi ne pas laisser un gestionnaire d'exception de haut niveau enregistre l'erreur afin de pouvoir revenir en arrière et éliminer le bogue? Il existe des moyens plus conviviaux pour rendre le développeur au courant du bogue que de tuer le programme.
Dans les cas où l'exception peut être empêchée, empêchez-la. Toujours.
Les exceptions de capture et de manutention sont chères et ne doivent jamais être utilisées pour un flux de contrôle normal. Un garde est bon marché et facile.
Cela ne dépend pas de ce que c'est la garde?
@Ashburlaczenko - Vous seriez fortement pressé de trouver un cas où une garde est plus coûteuse que la manipulation des exceptions.
Désolé, je faisais référence au un garde est bon marché partie.
Je ne suis pas d'accord avec le "toujours". C'est généralement mieux, mais pas toujours. Par exemple, si vous devez effectuer une demande de réseau afin de déterminer si une demande de réseau ultérieure réussirait, cela peut être Way plus cher que de simplement effectuer la deuxième demande de réseau et attraper une exception si elle était invalide. (C'est-à-dire si vous souhaitez extraire un fichier d'un serveur FTP, vous ne voulez peut-être pas vérifier s'il existe; laissez juste votre demande d'obtenir échouer si ce n'est pas le cas.)
@Servy: Mais il y a non demande de réseau que vous pouvez effectuer qui vous dira si une demande ultérieure réussira . Quelqu'un pourrait débrancher le câble réseau après la première demande. Une exception de réseau est une exception "exogène"; C'est hors de votre contrôle entièrement. C'est complètement différent d'une exception "Boneheaded" comme l'index hors de portée, où vous pouvez savoir avec une précision de 100% si l'exception sera lancée ou non.
@ERIFLIPPERT C'est vrai que vous ne pouvez pas savoir si la demande ultérieure réussira ou échoue sur la base d'une demande initiale, mais si elle est prévue que le dossier peut ne pas exister, vous veillez à ce que la volonté ultérieure ne sera que Jeter une exception dans des circonstances exceptionnelles et qu'aucune des exceptions ne représentera un flux de contrôle normal. Dans de la même manière, la vérification de la longueur de la matrice ne s'assurera jamais d'une exception d'exception lorsque vous accédez à la matrice, il suffit de vous assurer que toutes les exceptions pouvant être levées sont vraiment exceptionnelles, pas de flux de contrôle normal (c'est-à-dire FilabortException).
@Servy: Je suis d'accord avec vous. Dans certains cas, des tests pour savoir si une condition exceptionnelle peut probablement être moins chère que de tenter une opération qui finit par défaut. Dans d'autres cas, il peut être préférable d'essayer d'essayer l'opération et de faire face à l'échec (surtout si une tentative infructueuse n'aura aucun effet secondaire et ne sera plus coûteux qu'un test anticipé). On peut soutenir que les exceptions dans ce dernier cas pourraient être des exceptions "vexer" [c'est-à-dire. L'API aurait peut-être dû fournir une méthode "trydosomande" pour permettre la gestion de la condition attendue sans lancer une exception].
Dans les cas où .. Toujours dit que si d'autres cas sont également inclus, ce serait dans la plupart des cas (généralement?). C'est-à-dire que celles-ci sont exclues par la déclaration, alors toujours. Et si d'accord.
clause de garde. Vous ne voulez jamais utiliser essayer / attraper pour le flux de contrôle. Les exceptions attrapantes sont chères et doivent être évitées autant que vous le pouvez.
Plus précisément, il est préférable d'éviter d'essayer / attraper le flux de contrôle normal .
est-il préférable d'éviter une exception avec une clause de garde ou de prendre l'exception?
dans le cas des exceptions "Bonehead" telles que l'index hors de portée, toujours le premier.
dans le cas d'exceptions "exogènes", toujours ce dernier.
pro et inconvénients des deux méthodologies?
Il n'y a que des inconvénients de ce dernier dans le cas d'exceptions osseuses. Ils sont:
- Les exceptions sont incroyablement coûteuses comparées aux tests.
- Les exceptions sont destinées à modéliser les les situations de flux de contrôle exceptionnellement rares ; Si vous éventuellement accéder à un index hors de portée est normal alors n'écrivez pas un exception gestionnaire.
- Les exceptions sont rapportées comme des exceptions "de première chance" aux auditeurs même si l'exception est manipulée . De nombreux systèmes - ASP, par exemple - Écoutez les exceptions de première chance, les enregistrer tous et traitent des composants qui en produisent beaucoup comme buggy , car ils sont . (J'ai une fois introduit une exception de première chance délibérée dans un chemin de code commun dans ASP et un jour plus tard, j'ai entendu parler de cela. Les tests de la buggy-Subsystem sont devenus fous.)
- Il y a quelques exceptions à exceptions que j'appelle les exceptions "Boneheaded" - Null Dréréférence, Index hors de portée, et ainsi de suite, car ils sont si faciles à éviter et à indiquer des échecs si évidemment dangereux qu'ils devraient Toujours être traité comme des bugs fatals et jamais manipulé (sauf si le "gestionnaire" ne les regarde avant de fermer le processus.) Ne gérez pas le bogue, élimine le bogue < / em>.
Enfin, vous devriez lire mon article sur ce sujet.
J'utilise votre message comme guide lors du codage. Je jette Boneheaded Exceptions à l'aide de contrats de code, ont tryx méthodes au lieu de lancer vexing exceptions, et gérer toutes les exceptions exogènes exceptions .
Les clauses de garde peuvent être utiles avec des exceptions exogènes dans les cas où il existe un moyen peu coûteux de prédire avec une probabilité raisonnable si une opération réussira ou échoue. Par exemple, si on va écrire un concert de données à un ou plusieurs fichiers, il peut être utile de vérifier que cet espace existe avant de commencer. Même si on vérifie à l'avance l'espace, il faut encore être préparé pour la possibilité que cela n'existe peut-être pas plus tard, mais si on peut signaler un problème plus tôt, il faut essayer de le faire.
Si vous pouvez éviter l'exception, c'est mieux car les exceptions ont des frais généraux.
Si vous attendez quelque chose à l'index 3, c'est une erreur si vous ne l'avez pas là-bas ... Il est préférable de fermer votre application et de loger cette erreur au lieu d'attraper une exception ou d'essayer de le résoudre. .
@Anirudh: Que se passe-t-il si vous analysez un fichier censé être correctement formaté et que les articles seront placés dans une collection basée sur ce qui est dans le fichier? Si la seule action de récupération on voudrait au cas où le fichier est invalide est d'avoir le
Parsefile Jeton de routine une exception indiquant que le fichier ne pouvait pas être chargé, en essayant diverses opérations et attraper toutes les exceptions qui se produisent sembleraient Nettoyant que d'avoir des clauses de garde à chaque endroit dont le seul but est de jeter une exception si quelque chose ne va pas.