Supposons que j'ai trois fonctions DOA (), DOB () et DOC () dans un programme C # où je sais que DOA () appellera DOB () qui appelle à son tour DOC ().
Etant donné que Doc () doit interagir avec une base de données, je sais que cela pourrait très bien générer des exceptions qu'il ne pourrait pas résoudre à l'attention de l'utilisateur. Pour le moment, j'ai le code qui pourrait jeter l'erreur dans un coup d'essai / attraper sur DOC (), puis l'appel à DOC () dans DOB () dans un autre essai / capture et de la même manière l'appel à DOB () dans DOA () En Type / Catch Block. Cela me permet de simplement utiliser un lancer; Pour lancer l'exception jusqu'à DOA () où quelque chose peut raisonnablement être fait pour afficher cela à l'utilisateur.
Cela semble un peu comme Overkill cependant. Je me demande si je ne prévois pas de traiter avec l'exception dans DOB () ou de DOC () si je peux simplement vous débarrasser des blocs Essayer / Catch.
En supposant qu'il n'y ait pas de blocages enfin impliqués, quelle est la meilleure pratique pour traiter des situations comme celle-ci?
7 Réponses :
Oui, je me débarrasserais des blocs Essayer / Catch - laissez simplement l'exception propager au niveau supérieur, puis l'attraper là-bas. Attraper une exception juste à Retirhow avec Lancer; code> n'est tout simplement pas utile, bien que la variation suivante soit réellement nocive car elle détruit les informations de la trace de la pile: catch (Exception exception)
{
throw exception;
}
Vous n'avez besoin que d'attraper si vous avez l'intention de faire quelque chose (ou essayez d'arrêter la propagation). Si vous ne attrapez pas, cela va à la capture dans l'appelant. Dans votre cas, il semble que la DOA () (ou éventuellement son appelant, selon l'endroit où vous pouvez le gérer) est la seule fonction qui a besoin d'essayer / attraper.
Si vos blocs de capture sont comme ceci: alors ils sont effectivement inutiles. Vous ne manipulez pas vraiment l'exception - ne vous inquiétez pas avec Test / Catch du tout. Personnellement, j'ai très peu d'essais / attraper des blocs de mon code - et bien qu'il y ait beaucoup implicite try / enfin bloque, la plupart sont dus à à l'aide des déclarations .
exceptions à bulles de la pile d'appels.
Si la méthode où l'exception se produit ne le gère pas, l'appelant des méthodes l'obtient. Si l'appelant ne le gère pas, cela augmente la pile d'appels jusqu'à ce que le cadre le gère et bloque votre application.
Pour répondre à votre question: il n'est pas nécessaire de repousser une exception dans votre cas.
IMHO, une exception doit être attrapée le moins de fois possible, c'est une opération assez coûteuse d'attraper une exception.
Le cas peut arriver où vous traversez des couches d'application et peut vouloir que une couche se connecte / retire et que la couche suivante ait également besoin de l'attraper. Mais dans votre cas, ce n'est qu'une seule couche donc je dirais à la plus haute place de la pile d'appels où vous pouvez faire quelque chose à l'exception, le loger et faire votre logique commerciale.
Ne pas entrer dans la vraie / fausseté de votre déclaration "C'est en fait une opération assez coûteuse pour attraper une exception", vous auriez du mal à me convaincre que cela compte réellement.
Ce n'est pas pour moi de vous dire que la performance de votre application importe.
Soit vous avez complètement manqué le point, soit je n'ai pas fait un travail efficace de la communiquer; C'est très probablement ce dernier, alors veuillez accepter mes excuses pour cela. Je vais élaborer. Je doute sérieusement que les caractéristiques de performance d'attraper une exception importante. Pour la plupart, il est peu probable qu'il s'agisse d'un goulot d'étranglement dans une application réaliste; N'oubliez pas que les exceptions concernent des situations exceptionnelles. De plus, une exception indique généralement que l'état du système est mauvais et à ce moment-là, la performance n'a pas d'importance.
En bref, la réponse à votre question est oui. La seule raison d'attraper une exception est de faire quelque chose avec elle. Si vous ne pouvez rien faire d'utile avec Doc (), laissez-la simplement bouillir.
C'est toujours une bonne pratique d'essayer de prendre des blocs de capture sur les points d'entrée à votre code (généralement dans les gestionnaires d'événements dans une application Win Forms) afin que rien ne passe non capturé. À ce moment-là, ce que vous pouvez faire avec cela, c'est dire à l'utilisateur.
Toutefois, vous pouvez également vouloir mettre en place des gestionnaires de niveau inférieurs, le cas échéant, s'ils peuvent prendre des mesures raisonnables. Par exemple, dans DOC (), vous voudrez peut-être attraper des exceptions à faire avec des blocages et une réparation. À un certain niveau, vous pouvez également souhaiter attraper des erreurs de contrainte et lancer des erreurs ciblées plus significatives d'utilisateur à leur place. J'ai un publication du blog à ce sujet ici .
Type d'exception que vous allez attraper peut être différent à tous les niveaux, je ne suis pas sûr de ce que vous faites dans 3 niveaux, mais en haut de la pile, vous ne pouvez peut-être que 1 type d'exception, dans le niveau inférieur pourrait être un type d'exception différent, ce qui oblige un peu u à utiliser un type d'exception large, puis spécifique, ce qui pourrait ne pas avoir d'informations claires.
Cela dépend donc des types d'exceptions que vous lancerez.