Meilleures pratiques pour attraper et relancer les exceptions .NET

Question

Quelles sont les meilleures pratiques à prendre en compte pour attraper les exceptions et les relancer ? Je veux m'assurer que le Exception de l'objet InnerException et la trace de la pile sont préservées. Y a-t-il une différence entre les blocs de code suivants dans la façon dont ils gèrent cette situation ?

try
{
    //some code
}
catch (Exception ex)
{
    throw ex;
}

Vs :

try
{
    //some code
}
catch
{
    throw;
}

Answer 1

Le moyen de préserver la trace de la pile est d'utiliser la fonction throw; Ceci est également valable

try {
  // something that bombs here
} catch (Exception ex)
{
    throw;
}

throw ex; revient à lancer une exception à partir de ce point, de sorte que le suivi de la pile n'ira que jusqu'à l'endroit où vous émettez l'instruction throw ex; déclaration.

Mike est également correct, en supposant que l'exception vous permette de passer une exception (ce qui est recommandé).

Karl Seguin a un excellent article sur la gestion des exceptions dans son fondations de la programmation e-book également, qui est une grande lecture.

Edit : Lien fonctionnel vers Fondements de la programmation pdf. Il suffit de chercher le mot "exception" dans le texte.

Answer 2

Si vous lancez une nouvelle exception avec l'exception initiale, vous conserverez également la trace de la pile initiale

try{
} 
catch(Exception ex){
     throw new MoreDescriptiveException("here is what was happening", ex);
}

Answer 3

En fait, il y a des situations où le throw ne préservera pas l'information StackTrace. Par exemple, dans le code ci-dessous :

try
{
  int i = 0;
  int j = 12 / i; // Line 47
  int k = j + 1;
}
catch
{
  // do something
  // ...
  throw; // Line 54
}

Le StackTrace indiquera que la ligne 54 a déclenché l'exception, alors qu'elle a été déclenchée à la ligne 47.

Unhandled Exception: System.DivideByZeroException: Attempted to divide by zero.
   at Program.WithThrowIncomplete() in Program.cs:line 54
   at Program.Main(String[] args) in Program.cs:line 106

Dans des situations comme celle décrite ci-dessus, il existe deux options pour préserver le StackTrace original :

Appel de la fonction Exception.InternalPreserveStackTrace

Comme il s'agit d'une méthode privée, elle doit être invoquée en utilisant la réflexion :

private static void PreserveStackTrace(Exception exception)
{
  MethodInfo preserveStackTrace = typeof(Exception).GetMethod("InternalPreserveStackTrace",
    BindingFlags.Instance | BindingFlags.NonPublic);
  preserveStackTrace.Invoke(exception, null);
}

J'ai l'inconvénient de m'appuyer sur une méthode privée pour préserver l'information StackTrace. Elle peut être modifiée dans les futures versions de .NET Framework. L'exemple de code ci-dessus et la solution proposée ci-dessous ont été extraits de Blog de Fabrice MARGUERIE .

Appel de Exception.SetObjectData

La technique ci-dessous a été suggérée par Anton Tykhyy comme réponse à En C#, comment puis-je relancer une InnerException sans perdre la trace de la pile ? question.

static void PreserveStackTrace (Exception e) 
{ 
  var ctx = new StreamingContext  (StreamingContextStates.CrossAppDomain) ; 
  var mgr = new ObjectManager     (null, ctx) ; 
  var si  = new SerializationInfo (e.GetType (), new FormatterConverter ()) ; 

  e.GetObjectData    (si, ctx)  ; 
  mgr.RegisterObject (e, 1, si) ; // prepare for SetObjectData 
  mgr.DoFixups       ()         ; // ObjectManager calls SetObjectData 

  // voila, e is unmodified save for _remoteStackTraceString 
} 

Bien qu'elle ait l'avantage de s'appuyer uniquement sur des méthodes publiques, elle dépend également du constructeur d'exceptions suivant (que certaines exceptions développées par des tiers ne mettent pas en œuvre) :

protected Exception(
    SerializationInfo info,
    StreamingContext context
)

Dans ma situation, j'ai dû choisir la première approche, car les exceptions soulevées par une bibliothèque tierce que j'utilisais n'implémentaient pas ce constructeur.

Answer 4

Quand vous throw ex vous lancez essentiellement une nouvelle exception et vous n'obtiendrez pas les informations de la trace de la pile originale. throw est la méthode préférée.

Answer 5

La règle de base est d'éviter d'attraper et de lancer le basique Exception objet. Cela vous oblige à être un peu plus intelligent en ce qui concerne les exceptions ; en d'autres termes, vous devriez avoir un catch explicite pour une SqlException afin que votre code de manipulation ne fasse pas quelque chose de mal avec une NullReferenceException .

Dans le monde réel, cependant, attraper et l'enregistrement l'exception de base est également une bonne pratique, mais n'oubliez pas de parcourir l'ensemble pour obtenir toute InnerExceptions ça aurait pu être le cas.