Est-ce une mauvaise pratique d'imbriquer 2 instructions catch en C#?

Question

Est-ce que le code suivant est une mauvaise pratique?

try //Try Overall Operation 
     { 
      try //Try section 1 of operation 
       { 

       } 
      catch(exception ex) 
       { 
        //handle exception code 
        //throw the exception 
     } 
catch (exception ex) 
     { 
      // send soap exception back to SOAP client. 
     } 

Je sais que d'un point de vue de l'examen des programmes, d'autres développeurs voyant 2 essais imbriqués directement comme ça peut se demander pourquoi, mais est totalement tabou, ou est-il accepté la pratique de nos jours?

Merci les gars, je suis d'accord avec vous tous sur le refactoring, va créer une méthode séparée pour la sous-fonctionnalité, la méthode devenait vraiment longue. Je suis très impressionné par vous tous qui avez ramassé cela ...

Answer 1

Non, je ne pense pas que ce soit une mauvaise pratique du tout. Si vous faites quelque chose dans le premier essai imbriqué que vous pouvez attraper et manipuler correctement, c'est très bien, surtout si vous "attrapez" différents types d'exceptions dans les deux gestionnaires.

Cependant, je dirais que c'est potentiellement une bonne occasion pour refactoriser, et diviser la section imbriquée dans une méthode séparée. Souvent, quand j'ai vu cela, c'est un signe que la méthode devrait être divisée en plus petites méthodes. Cependant, ce n'est pas toujours vrai.

Answer 2

À mon avis, il ne doit pas être. Parfois, vous voulez que du code soit exécuté dans le premier essai même si le code du second échoue.

Pourrait également ajouter que d'autres personnes ont raison dans ce qu'ils disent aussi. Je dis juste que ça ne doit pas toujours être mauvais. Dans un programme qui ne demande pas de performance, vous pouvez le faire comme bon vous semble.

Answer 3

Il est pas terrible, voir si vous ne pouvez pas résoudre tout cela en manipulant les types d'exception au besoin au lieu:

try 
{ 

} 
catch (SqlException ex) 
{ 
// Catches specific exception 
} 
catch (Exception ex) 
{ 
// Catch-all 
} 

Chaque fois que vous faites un try-catch vous créez un autre thread des déclarations encombrement readabilitiy. E.g .:

try 
{ 
    try 
    { 
    } 
    catch (Exception ex) 
    { 
    } 
} 
catch (Exception ex) 
{ 
} 

Answer 4

Cela dépend de ce que votre programme doit faire. Il est généralement préférable d'enrouler votre try/catch autour de la plus petite portée possible et de concentrer votre gestion des exceptions aussi étroitement que possible pour éviter tout comportement inattendu, les effets secondaires ou les bogues. Plusieurs fois cela signifiera avoir une séquence de blocs try/catch, ce qui est bien.

Answer 5

Je pense que cela dépend de la façon dont vous gérez l'exception interne. Il peut être très logique que votre prise intérieure là-bas doive faire quelque chose de complètement différent de ce qui tomberait dans la portée de la prise extérieure. La seule chose que vous voudriez éviter est de cacher l'exception interne comme étant la cause de l'exception extérieure. En d'autres termes, je recommande fortement

try 
{ 
    // Do something 
    try 
    { 
     // Do something 
    } 
    catch(MyException e) 
    { 
     // handle 
     throw; // <--- This is important, it rethrows the same exception while maintaining the stack trace. This is *different* from "throw e" 
    } 
} 
catch(AnotherException e) 
{ 
    // handle 
} 

Answer 6

Ce n'est pas une mauvaise pratique, tant que la logique le justifie. Par exemple, si le try le plus externe est destiné à intercepter une exception SQL et que le try le plus interne correspond à une exception d'E/S, il peut être raisonnable de le faire. Cependant, veillez à ne pas avoir de clauses catch-all qui couvrent un grand nombre de lignes de code. Ces ne sont pas une bonne pratique.

Answer 7

Non, ce n'est pas nécessairement une mauvaise forme.

Tout comme la plupart de ces types de questions (par exemple, est-ce que le mal est fait ?, Est-ce pour (;;) le mal?) Ces choses ont leur place et sont acceptables si elles sont utilisées.

Answer 8

S'il existe une exception que vous pouvez gérer à l'intérieur du premier bloc try et continuer malgré tout avec succès, je ne pense pas qu'il y ait un problème. Si c'est juste pour faire quelque chose et relancer, ajoutez simplement un autre bloc catch pour le type spécifique d'exception que vous recherchez et gérez-le.