Utilisation efficace du bloc try / catch?

Les blocs catch doivent-ils être utilisés pour écrire la logique, c'est-à-dire gérer le contrôle de flux, etc.? Ou tout simplement pour lever des exceptions? Cela affecte-t-il l'efficacité ou la maintenabilité du code?

Quels sont les effets secondaires (s'il y en a) de l'écriture de la logique dans le bloc catch?

ÉDITER:

J'ai vu une classe Java SDK dans laquelle ils ont écrit la logique à l'intérieur du bloc catch. Par exemple (extrait de java.lang.Integerclasse):

        try {
            result = Integer.valueOf(nm.substring(index), radix);
            result = negative ? new Integer(-result.intValue()) : result;
        } catch (NumberFormatException e) {
            String constant = negative ? new String("-" + nm.substring(index))
                                       : nm.substring(index);
            result = Integer.valueOf(constant, radix);
        }

EDIT2 :

Je suivais un tutoriel où ils le considèrent comme un avantage d'écrire la logique des cas exceptionnels à l'intérieur des exceptions:

Les exceptions vous permettent d'écrire le flux principal de votre code et de traiter les cas exceptionnels ailleurs.

Des directives spécifiques quand écrire la logique dans le bloc catch et quand ne pas le faire?

L'exemple que vous citez est dû à une mauvaise conception de l'API (il n'existe aucun moyen propre de vérifier si une chaîne est un entier valide, sauf en essayant de l'analyser et en interceptant l'exception).

Au niveau technique, throw et try / catch sont des constructions de flux de contrôle qui vous permettent de sauter la pile des appels, rien de plus et rien de moins. Le fait de sauter la pile d'appels connecte implicitement du code qui n'est pas rapproché dans la source, ce qui est mauvais pour la maintenabilité . Il ne doit donc être utilisé que lorsque vous en avez besoin et les alternatives sont encore pires. Le cas largement accepté où les alternatives sont pires est la gestion des erreurs (codes de retour spéciaux qui doivent être vérifiés et transmis manuellement à chaque niveau de la pile d'appels).

Si vous avez un cas où les alternatives sont pires (et que vous les avez vraiment examinées attentivement), alors je dirais que lancer et essayer / attraper pour le flux de contrôle est correct. Le dogme n'est pas un bon substitut au jugement.

C'est quelque chose qui a tendance à dépendre du langage et du paradigme.

La plupart de mon travail se fait en Java (et parfois en C ++). La tendance est de n'utiliser les exceptions que pour des conditions exceptionnelles. Il y a quelques questions sur Stack Overflow sur la surcharge de performances des exceptions en Java , et comme vous pouvez le voir, ce n'est pas exactement négligeable. Il existe également d'autres préoccupations, telles que la lisibilité et la maintenabilité du code. Lorsqu'elles sont utilisées correctement, les exceptions peuvent déléguer la gestion des erreurs aux composants appropriés.

Cependant, en Python, l'idée qu'il est plus facile de demander pardon que la permission règne. Dans la communauté Python, cela est connu sous le nom d' EAFP , qui contraste avec l' approche "regardez avant de sauter" ( LBYL ) dans les langages de style C.

Ce n'est pas la meilleure façon de penser aux blocs try / catch. La façon de penser aux blocs try / catch est la suivante: un échec s'est produit, où est le meilleur endroit pour faire face à CET échec spécifique. Cela peut être la ligne de code la plus proche, elle peut se situer à vingt niveaux dans la chaîne d'appel. Où qu'il soit, c'est là qu'il devrait être.

Ce que fait le bloc catch dépend de l'erreur et de ce que vous pouvez y faire. Parfois, il peut simplement être ignoré (échec de la suppression d'un fichier de travail sans données importantes), parfois il sera utilisé pour définir la valeur de retour d'une fonction sur vrai ou faux (méthode d'analyse par int de java), parfois vous quitterez le programme . Tout cela dépend de l'erreur.

La partie importante à comprendre est la suivante: catch block == Je sais comment y faire face.

Les blocs catch ne doivent être utilisés que pour gérer les exceptions, rien d'autre et jamais pour le flux de contrôle. Dans toute situation où vous souhaitez utiliser des exceptions pour gérer le flux, vous feriez mieux de vérifier les conditions préalables.

Le traitement du flux avec des exceptions est lent et sémantiquement incorrect.

Les blocs catch doivent-ils être utilisés pour écrire la logique, c'est-à-dire gérer le contrôle de flux, etc.? Ou tout simplement pour lever des exceptions? Cela affecte-t-il l'efficacité ou la maintenabilité du code?

Tout d'abord, oubliez la notion selon laquelle "les exceptions doivent être utilisées pour des conditions exceptionnelles". Arrêtez également de vous soucier de l'efficacité, jusqu'à ce que vous ayez un code qui fonctionne de manière inacceptable et que vous ayez mesuré pour savoir où se situe le problème.

Le code est plus facile à comprendre lorsque les actions suivent dans une séquence simple, sans conditions. Les exceptions améliorent la maintenabilité en supprimant la vérification des erreurs du flux normal. Peu importe que l'exécution suive le flux normal 99,9% du temps ou 50% du temps ou 20% du temps.

Lance une exception lorsqu'une fonction n'est pas en mesure de renvoyer une valeur, lorsqu'une procédure n'est pas en mesure de terminer l'action attendue ou lorsqu'un constructeur est incapable de produire un objet utilisable. Cela permet aux programmeurs de supposer qu'une fonction renvoie toujours un résultat utilisable, une procédure termine toujours l'action demandée, un objet construit est toujours dans un état utilisable.

Le plus gros problème que je vois avec le code de gestion des exceptions est que les programmeurs écrivent des blocs try / catch alors qu'ils ne devraient pas. Par exemple, dans la plupart des applications Web, si une demande de base de données lève une exception, rien ne peut être fait dans le contrôleur. Une clause de capture générique au plus haut niveau suffit. Ensuite, le code du contrôleur peut parfaitement ignorer la possibilité que le disque soit tombé en panne ou que la base de données soit hors ligne ou autre.

Les blocs de capture ne doivent pas être utilisés pour écrire la logique du code. Ils ne doivent être utilisés que pour gérer les erreurs. Un exemple est (1) nettoyer toutes les ressources allouées, (2) imprimer un message utile, et (3) quitter normalement.

Il est vrai que les exceptions peuvent être abusées et provoquer des gotoeffets indésirables . Mais cela ne les rend pas inutiles. Lorsqu'ils sont correctement utilisés , ils peuvent améliorer de nombreux aspects de votre code.