Voilà, en aidant un collègue sur une de ses applications, je me suis rendue compte qu'il y avait encore des doutes sur la meilleure façon de remonter une exception (meme parmi l'équipe d'architecture). Les logs applicatifs n'étaient pas très bavards et remontaient la moitié des informations qu'il aurrait pu donner.
J'ai donc fait un petit prototype pour prouver que le meilleur usage de "throw" reste celui-ci :
- Soit une Classe1 qui fait une division par zéro, et en cas d’erreur renvoit une exception.
- Soit une Classe2 qui appelle la division par zéro de la Classe1, en faisant un try catch.
- Soit une application winform1 qui appelle Classe2.
Si vous gérez le code des exceptions comme ceci :
try
{
//mon code
}
catch (Exception ex)
{
throw ex;
}
Vous obtiendrez cela :
Si par contre vous vous contentez de faire un throw tout court comme ceci :
try
{
//mon code
}
catch (Exception ex)
{
throw;
}
Vous obtiendrez beaucoup plus d’informations sur l’origine de l’erreur :
La règle à retenir est donc que si vous faites un « throw ex » (surtout sans l’enrichir au passage) , vous allez perdre une partie des informations, et le lieu exact de l’erreur.
Règle à penser à appliquer dans tous vos codes :
Faire un
catch (Exception ex)
{
throw;
}
Je m’excuse auprès des personnes qui savaient déjà tout ça, mais une petite piqure de rappel ne peut pas faire de mal J
Elise
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
