Pourquoi attraper et relancer une exception en C# ?

Question

Je regarde l'article C# - Objet de transfert de données sur les DTO sérialisables.

L'article comprend ce morceau de code :

public static string SerializeDTO(DTO dto) {
    try {
        XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
        StringWriter sWriter = new StringWriter();
        xmlSer.Serialize(sWriter, dto);
        return sWriter.ToString();
    }
    catch(Exception ex) {
        throw ex;
    }
}

Le reste de l'article semble sain et raisonnable (pour un noob), mais ce try-catch-throw lance une WtfException... N'est-ce pas exactement l'équivalent de ne pas gérer du tout les exceptions ?

Ergo :

public static string SerializeDTO(DTO dto) {
    XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
    StringWriter sWriter = new StringWriter();
    xmlSer.Serialize(sWriter, dto);
    return sWriter.ToString();
}

Ou est-ce que je rate quelque chose de fondamental dans la gestion des erreurs en C# ? C'est à peu près la même chose qu'en Java (sauf les exceptions vérifiées), n'est-ce pas ? ... C'est-à-dire qu'ils ont tous deux raffiné le C++.

La question de Stack Overflow La différence entre relancer une capture sans paramètre et ne rien faire ? semble confirmer ma thèse selon laquelle le "try-catch-throw" est une erreur.

---

EDIT :

Juste pour résumer pour ceux qui trouveront ce fil à l'avenir...

NE PAS

try {
    // Do stuff that might throw an exception
}
catch (Exception e) {
    throw e; // This destroys the strack trace information!
}

Les informations de la trace de la pile peuvent être cruciales pour identifier la cause profonde du problème !

DO

try {
    // Do stuff that might throw an exception
}
catch (SqlException e) {
    // Log it
    if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
        // Do special cleanup, like maybe closing the "dirty" database connection.
        throw; // This preserves the stack trace
    }
}
catch (IOException e) {
    // Log it
    throw;
}
catch (Exception e) {
    // Log it
    throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
}
finally {
    // Normal clean goes here (like closing open files).
}

Attrapez les exceptions les plus spécifiques avant les moins spécifiques (tout comme Java).

---

Références :

• MSDN - Traitement des exceptions
• MSDN - try-catch (Référence C#)

Answer 1

Tout d'abord, la façon dont le code de l'article le fait est mauvaise. throw ex réinitialisera la pile d'appels dans l'exception au point où se trouve l'instruction throw, perdant ainsi l'information sur l'endroit où l'exception a été créée.

Deuxièmement, si vous vous contentez d'attraper et de relancer comme ça, je ne vois pas de valeur ajoutée, l'exemple de code ci-dessus serait tout aussi bien (ou, étant donné le throw ex encore mieux) sans le try-catch.

Cependant, il existe des cas où vous pouvez vouloir attraper et relancer une exception. La journalisation pourrait être l'un de ces cas :

try 
{
    // code that may throw exceptions    
}
catch(Exception ex) 
{
    // add error logging here
    throw;
}

Answer 2

Ne faites pas ça,

try 
{
...
}
catch(Exception ex)
{
   throw ex;
}

Vous perdrez les informations de la trace de la pile...

L'un ou l'autre,

try { ... }
catch { throw; }

OU

try { ... }
catch (Exception ex)
{
    throw new Exception("My Custom Error Message", ex);
}

L'une des raisons pour lesquelles vous pourriez vouloir relancer est que vous traitez différentes exceptions, par exemple par exemple

try
{
   ...
}
catch(SQLException sex)
{
   //Do Custom Logging 
   //Don't throw exception - swallow it here
}
catch(OtherException oex)
{
   //Do something else
   throw new WrappedException("Other Exception occured");
}
catch
{
   System.Diagnostics.Debug.WriteLine("Eeep! an error, not to worry, will be handled higher up the call stack");
   throw; //Chuck everything else back up the stack
}

Answer 3

C# (avant C# 6) ne prend pas en charge les "exceptions filtrées" CIL, contrairement à VB. Ainsi, en C# 1-5, l'une des raisons de relancer une exception est que l'on ne dispose pas de suffisamment d'informations au moment de catch() pour déterminer si l'on voulait réellement attraper l'exception.

Par exemple, en VB, vous pouvez faire

Try
 ..
Catch Ex As MyException When Ex.ErrorCode = 123
 .. 
End Try

...qui ne pouvait pas gérer les MyExceptions avec des valeurs ErrorCode différentes. Dans le C# antérieur à la version 6, il fallait attraper et relancer l'exception MyException si le ErrorCode n'était pas 123 :

try 
{
   ...
}
catch(MyException ex)
{
    if (ex.ErrorCode != 123) throw;
    ...
}

Depuis C# 6.0, vous pouvez filtrer tout comme avec VB :

try 
{
  // Do stuff
} 
catch (Exception e) when (e.ErrorCode == 123456) // filter
{
  // Handle, other exceptions will be left alone and bubble up
}

Answer 4

Une raison valable pour relancer des exceptions peut être que vous voulez ajouter des informations à l'exception, ou peut-être envelopper l'exception originale dans une exception de votre propre création :

public static string SerializeDTO(DTO dto) {
  try {
      XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
      StringWriter sWriter = new StringWriter();
      xmlSer.Serialize(sWriter, dto);
      return sWriter.ToString();
  }
  catch(Exception ex) {
    string message = 
      String.Format("Something went wrong serializing DTO {0}", DTO);
    throw new MyLibraryException(message, ex);
  }
}

Answer 5

N'est-ce pas exactement l'équivalent de ne pas pas du tout les exceptions ?

Pas exactement, ce n'est pas la même chose. Il réinitialise le suivi de pile de l'exception. Bien que je sois d'accord que c'est probablement une erreur, et donc un exemple de mauvais code.