MethodA appelle un MethodB qui appelle à son tour MethodC.

Il n'y a PAS de gestion des exceptions dans MethodB ou MethodC. Mais il existe une gestion des exceptions dans MethodA.

Dans MethodC, une exception se produit.

Maintenant, cette exception est en train de bouillonner jusqu'à MethodA, qui la gère correctement.

Quel est le probleme avec ca?

Dans mon esprit, à un moment donné, un appelant exécutera MethodB ou MethodC, et lorsque des exceptions surviennent dans ces méthodes, ce que l'on obtiendra de la gestion des exceptions à l'intérieur de ces méthodes, qui consiste essentiellement en un bloc try / catch / finally au lieu de simplement laisser les bulles à l'appelé?

La déclaration ou le consensus autour de la gestion des exceptions est à lancer lorsque l'exécution ne peut pas continuer pour cette raison - une exception. Je comprends ça. Mais pourquoi ne pas capturer l'exception plus haut dans la chaîne au lieu d'avoir des blocs try / catch tout en bas.

Je le comprends quand vous devez libérer des ressources. C'est une toute autre affaire.

En règle générale, ne capturez pas les exceptions à moins de savoir quoi faire avec elles. Si MethodC lève une exception, mais que MethodB n'a aucun moyen utile de la gérer, elle devrait permettre à l'exception de se propager jusqu'à MethodA.

Les seules raisons pour lesquelles une méthode doit avoir un mécanisme de capture et de remise à zéro sont les suivantes:

• Vous souhaitez convertir une exception en une exception plus significative pour l'appelant ci-dessus.
• Vous souhaitez ajouter des informations supplémentaires à l'exception.
• Vous avez besoin d'une clause de blocage pour nettoyer les ressources qui seraient divulguées sans une.

Sinon, intercepter des exceptions au mauvais niveau a tendance à produire un code qui échoue de manière silencieuse sans fournir de retour d'information utile au code appelant (et finalement à l'utilisateur du logiciel). L'alternative consistant à intercepter une exception puis à la rediffuser immédiatement est inutile.

Quel est le probleme avec ca ?

Absolument rien.

Maintenant, cette exception est en train de bouillonner jusqu'à MethodA, qui la gère correctement.

"le gère de manière appropriée" est la partie importante. C'est le noeud de la gestion des exceptions structurées.

Si votre code peut faire quelque chose "utile" avec une exception, allez-y. Si non, alors laissez bien seul.

. . . pourquoi ne pas capturer l'exception plus loin dans la chaîne au lieu d'avoir des blocs try / catch tout en bas.

C'est exactement ce que vous devriez faire. Si vous lisez du code dont le gestionnaire / renifleur est "tout en bas", alors vous êtes (probablement) en train de lire un code assez médiocre.

Malheureusement, certains développeurs voient dans les blocs catch comme un code "code chaud" qu'ils jettent (sans jeu de mots) dans toutes les méthodes qu'ils écrivent, souvent parce qu'ils ne "reçoivent" pas vraiment "Exception Handling" et pensent devoir ajouter quelque chose d'aussi que les exceptions ne "s'échappent" pas et ne tuent pas leur programme.

Une partie de la difficulté ici est que, la plupart du temps, ce problème ne sera même pas remarqué, car les exceptions ne sont pas lancées tout le temps, mais quand elles le seront , le programme va perdre énormément de temps et effort en décapitant graduellement la pile d’appel pour arriver à un endroit qui fait réellement quelque chose d’utile avec Exception.

Vous devez faire la différence entre les bibliothèques et les applications.

Les bibliothèques peuvent lancer des exceptions non capturées librement

Lorsque vous concevez une bibliothèque, vous devez à un moment donné penser à ce qui peut mal tourner. Les paramètres peuvent être dans la mauvaise plage ou nulldes ressources externes peuvent ne pas être disponibles, etc.

Le plus souvent, votre bibliothèque n'aura pas le moyen de les traiter de manière sensée . La seule solution sensée est de lancer une exception appropriée et de laisser le développeur de l'application s'en occuper.

Les applications doivent toujours, à un moment donné, intercepter des exceptions

Quand une exception est interceptée, j'aime bien les classer comme des erreurs ou des erreurs fatales . Une erreur normale signifie qu'une seule opération dans mon application a échoué. Par exemple, un document ouvert n'a pas pu être enregistré car la destination n'était pas accessible en écriture. La seule pensée sensée pour l'application consiste à informer l'utilisateur que l'opération n'a pas pu être complétée avec succès, à donner des informations lisibles par l'homme concernant le problème, puis à laisser l'utilisateur décider de la suite.

Une erreur fatale est une erreur dont la logique principale de l'application ne peut pas récupérer. Par exemple, si le pilote du périphérique graphique se bloque dans un jeu vidéo, il n’ya aucun moyen pour l’application d’en informer «gracieusement» l’utilisateur. Dans ce cas, un fichier journal doit être écrit et, si possible, l'utilisateur doit être informé d'une manière ou d'une autre.

Même dans un cas aussi grave, l'application doit gérer cette exception de manière significative. Ceci peut inclure l'écriture d'un fichier journal, l'envoi d'un rapport d'incident, etc. Il n'y a aucune raison pour que l'application ne réponde en aucune façon à l'exception.

Ce qui ne va pas avec le modèle que vous décrivez, c'est que la méthode A n'aura aucun moyen de distinguer trois scénarios:

1. La méthode B a échoué de manière anticipée.

2. La méthode C a échoué d’une manière qui n’était pas prévue par la méthode B, mais qui effectuait une opération pouvant être abandonnée en toute sécurité.

3. La méthode C a échoué d’une manière qui n’était pas prévue par la méthode B, mais qui effectuait une opération qui a placé les objets dans un état supposé incohérent supposé être temporaire que B n’a pas nettoyé à cause de l’échec de C.

La seule façon dont la méthode A sera capable de distinguer ces scénarios sera si l'exception levée par B inclut des informations suffisantes à cette fin ou si la pile déroulée pour la méthode B fait que l'objet est laissé dans un état explicitement invalidé . Malheureusement, la plupart des structures d'exception rendent les deux modèles difficiles, ce qui oblige les programmeurs à prendre des décisions de conception "moins graves".