Pour lancer des exceptions, j'utilise généralement des classes d'exceptions intégrées, par exemple. ArgumentNullException
et NotSupportedException
. Cependant, je dois parfois utiliser une exception personnalisée et dans ce cas, j'écris:
class SlippedOnABananaException : Exception { }
class ChokedOnAnAppleException : Exception { }
etc. Ensuite, je jette et attrape ceux-ci dans mon code. Mais aujourd'hui, je suis tombé sur la classe ApplicationException
. Devrais-je l'utiliser à la place? C'est pour quoi?
Il semble inefficace d'avoir un grand nombre de classes Exception identiques avec des noms différents (je n'ai généralement pas besoin de fonctionnalités individuelles). Mais je n'aime pas l'idée d'attraper un générique ApplicationException
et d'avoir à utiliser du code supplémentaire pour déterminer quelle était l'erreur.
Où ApplicationException
devrait-il s'inscrire dans mon code?
Selon le remarques dans msdn:
Les applications utilisateur, et non le Common Language Runtime, lancent des exceptions personnalisées issues de la classe ApplicationException. La classe ApplicationException fait la distinction entre les exceptions définies par les applications et les exceptions définies par le système.
Si vous concevez une application devant créer ses propres exceptions, il vous est conseillé de dériver des exceptions personnalisées à partir de la classe Exception. À l'origine, on pensait que les exceptions personnalisées devraient provenir de la classe ApplicationException; toutefois, dans la pratique, cela n’a pas apporté de valeur ajoutée significative. Pour plus d'informations, voir Meilleures pratiques pour la gestion des exceptions.
Dérivez-les de Exception
. De plus, je ne vois pas de problème à créer de nouvelles exceptions pour vos cas, aussi longtemps que cela est justifié. Si vous rencontrez un cas où il existe déjà une exception dans la structure, utilisez-la sinon, lancez la vôtre.
La réponse courte est: nulle part.
Il s’agit d’une relique du passé, où Microsoft avait prévu que les développeurs héritent de toutes leurs exceptions personnalisées de ApplicationException. Peu de temps après, ils ont changé d'avis et ont indiqué que les exceptions personnalisées devraient provenir de la classe d'exception de base. Voir Meilleures pratiques pour la gestion des exceptions sur MSDN.
L’une des raisons les plus largement diffusées est un extrait de Jeffery Richter in Framework Design Guidelines :
System.ApplicationException est une classe qui ne doit pas faire partie du .NET Framework. L’idée de départ était que les classes dérivées de SystemException indiqueraient des exceptions émises par le CLR (ou le système) lui-même, alors que les exceptions non-CLR seraient dérivées de ApplicationException . Cependant, beaucoup de classes d'exception ne suivaient pas ce modèle. Par exemple, TargetInvocationException (qui est levé par le CLR) est dérivé de ApplicationException . Ainsi, la classe ApplicationException a perdu toute signification. La raison de dériver de cette classe de base est de permettre à un code plus haut dans la pile d'appels d'attraper la classe de base. Il n'était plus possible d'intercepter toutes les exceptions d'application.
Donc là vous l'avez. Le résumé est que ApplicationException n'est pas nuisible , mais simplement inutile .
Dans la conception initiale, dans .NET 1.0, il était prévu que le framework proprement dit jette SystemException
et dérive; tandis que les applications utilisateur - jetteront ApplicationException
et dérivés.
Mais plus tard, dans .NET 2.0, cela a été supprimé.
Dérivez donc de Exception
.