La gestion des exceptions try catch à l'intérieur de catch

Je suis récemment tombé sur le code écrit par un collègue programmeur en qui il avait une instruction try-catch à l'intérieur d'un hic!

Veuillez pardonner mon incapacité à coller le code, mais ce qu'il a fait quelque chose de similaire à ceci:

try
{
 //ABC Operation
}
catch (ArgumentException ae)
{
   try
   {
      //XYZ Operation
   }
   catch (IndexOutOfRangeException ioe)
   {
      //Something
   }
}

Personnellement, je pense que c'est une des plus pauvres de code que j'ai jamais vu!
Sur une échelle de 1 à 10, combien de temps pensez-vous que je devrais aller et de lui donner un morceau de mon esprit, ou suis-je sur-réaction?

EDIT:
Ce qu'il est en train de faire dans le catch, il est de l'exécution de certaines opérations qui peut/doit être fait lors de la première essayer échoue. Mon problème est d'avoir un code propre et maintenable. Déléguer l'exception de la première prise à une autre fonction ou la fonction d'appel serait OK, mais en ajoutant plus de code qui peut ou ne peut pas lancer une exception dans la première capture, est ce que je ressentais n'était pas bon. J'essaie d'éviter de multiples empilées "si" en boucle les déclarations, j'ai trouvé ce tout aussi mauvais.

C'est assez fréquent, donc sans voir ce que le code ne fait - il n'y a rien d'intrinsèquement mauvais avec cette.
Je préfère lui demander ce qu'il cherchait à atteindre.

InformationsquelleAutor topgun_ivard | 2010-08-19

137

Pourquoi est-ce mauvais? Ce n'est pas différent sur le plan conceptuel que:
```
void TrySomething() {
   try {


   } catch (ArgumentException) {
        HandleTrySomethingFailure();
   }
}

void HandleTrySomethingFailure() {
    try {

    } catch (IndexOutOfRangeException) {

    }
}
```
Avant d'y aller et de lui donner un morceau de votre cerveau (essayez le lobe pariétal, il est particulièrement choquant) , quelles sont exactement ce que vous allez lui dire? Comment allez-vous répondre à la proverbiale "pourquoi?"

Ce qui est encore plus ironique, c'est que quand la gigue inlines ce code, il va ressembler exactement comme votre exemple.

-Oisin
- Je suis totalement d'accord. Si vous vous sentez il ya quelque chose de mal avec son code et sont prêts à s'attaquer à lui en parler, il vaut mieux avoir une excellente alternative prêt à présenter.
- Yep. Le fractionnement de la imbriquée try-catch dans sa propre méthode est sur le meilleur qui peut être fait.
InformationsquelleAutor x0n

Voici un cas :

try{
    //Dangerous Operation
} catch (AnyException ae) {
    try {
        //Do rollback which can fail
    } catch (RollbackFailedException rfe) {
        //Log that
    }
} finally {
    try {
        //close connection but it may fail too
    } catch (IOException ioe) {
        //Log that
    }
}

C'est la même chose que @x0n dit. Vous pourriez avoir besoin pour gérer exception lors de la fermeture de ressources ou pendant que vous essayez de résoudre une situation par une autre exception.

Est-il plus propre façon de gérer cela.
L'utilisation d'une fantaisie d'exception/essayer/relance de gestion de package comme Polly.

InformationsquelleAutor Colin Hebert

18

Sans savoir ce que fait le code, il est impossible de dire. Mais ce n'est pas inhabituelle pour ce faire.

par exemple, si vous devez venir à bout de ressources, tandis que la gestion des exceptions, que ce soit clair code lui-même peut avoir la capacité de lancer des exceptions.

InformationsquelleAutor Brian Agnew

Vous devez vous connecter pour publier un commentaire.