À quoi sert ApplicationException dans .NET?

Pour lever des exceptions, j'utilise généralement des classes d'exceptions intégrées, par exemple ArgumentNullExceptionet NotSupportedException. Cependant, parfois j'ai besoin d'utiliser une exception personnalisée et dans ce cas j'écris:

class SlippedOnABananaException : Exception { }
class ChokedOnAnAppleException : Exception { }

etc. Ensuite, je lance et attrape ces derniers dans mon code. Mais aujourd'hui, je suis tombé sur la ApplicationExceptionclasse - devrais-je utiliser cela à la place? C'est pour quoi?

Il semble inefficace d'avoir beaucoup de classes d'exception effectivement identiques avec des noms différents (je n'ai généralement pas besoin de fonctionnalité individuelle). Mais je n'aime pas l'idée d'attraper un générique ApplicationExceptionet d'avoir à utiliser du code supplémentaire pour déterminer quelle était l'erreur.

Où doit ApplicationExceptions'inscrire mon code?

Selon les remarques dans msdn:

Les applications utilisateur, et non le Common Language Runtime, lancent des exceptions personnalisées dérivées de la classe ApplicationException. La classe ApplicationException fait la différence entre les exceptions définies par les applications et les exceptions définies par le système.

Si vous concevez une application qui doit créer ses propres exceptions, il est conseillé de dériver des exceptions personnalisées à partir de la classe Exception. On pensait à l'origine que les exceptions personnalisées devraient dériver de la classe ApplicationException; cependant, dans la pratique, cela ne s'est pas avéré apporter une valeur ajoutée significative. Pour plus d'informations, consultez Meilleures pratiques pour la gestion des exceptions.

Tirez-les de Exception. De plus, je ne vois pas de problème avec la création de nouvelles exceptions pour vos cas, tant que cela est justifié. Si vous rencontrez un cas où il y a déjà une exception dans le framework, utilisez-la, sinon, lancez la vôtre.

La réponse courte est: nulle part.

C'est une relique du passé, où Microsoft voulait que les développeurs héritent de toutes leurs exceptions personnalisées d'ApplicationException. Peu de temps après, ils ont changé d'avis et ont indiqué que les exceptions personnalisées devraient dériver de la classe Exception de base. Consultez Meilleures pratiques pour gérer les exceptions sur MSDN.

L'une des raisons les plus largement diffusées à cet égard provient d'un extrait de Jeffery Richter dans Framework Design Guidelines :

System.ApplicationException est une classe qui ne doit pas faire partie du .NET Framework. L'idée originale était que les classes dérivées de SystemException indiqueraient les exceptions levées à partir du CLR (ou du système) lui-même, tandis que les exceptions non CLR seraient dérivées d' ApplicationException . Cependant, de nombreuses classes d'exception n'ont pas suivi ce modèle. Par exemple, TargetInvocationException (qui est levée par le CLR) est dérivé d' ApplicationException . Ainsi, la classe ApplicationException a perdu toute signification. La raison de dériver de cette classe de base est de permettre à du code plus haut dans la pile d'appels d'attraper la classe de base. Il n'était plus possible d'attraper toutes les exceptions d'application.

Alors là vous l'avez. Le résumé analytique est qu'ApplicationException n'est pas nuisible , juste inutile .

Dans la conception initiale, dans .NET 1.0, il était prévu que le framework lui-même soit lancé SystemExceptionet dérivé; tandis que les applications utilisateur - jettera ApplicationExceptionet dérivé.

Mais plus tard, dans .NET 2.0, cela a été abandonné.

Ainsi dérivent de Exception.