A quoi sert ApplicationException dans .NET?

Question

Lancer des exceptions, j'ai l'habitude de l'utilisation intégrée dans les classes d'exception, par exemple, ArgumentNullException et NotSupportedException. Cependant, parfois, j'ai besoin d'utiliser une exception personnalisée et dans ce cas, j'écris:

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

et ainsi de suite. Puis-je lancer et à attraper ces dans mon code. Mais aujourd'hui, je suis tombé sur l' ApplicationException classe - dois-je utiliser qui à la place? Quel est-il?

Il semble inefficace d'avoir beaucoup de efficacement identiques classes d'Exception avec des noms différents (je n'ai généralement pas besoin de tout individu de fonctionnalité). Mais je n'aime pas l'idée d'attraper un générique ApplicationException et d'avoir à utiliser un code supplémentaire pour déterminer ce que l'erreur a été.

Où dois - ApplicationException en accord avec mon code?

Answer 1

La réponse courte est: nulle part.

C'est une relique du passé, où Microsoft destiné aux développeurs d'hériter de tous leurs personnalisé exceptions de ApplicationException. Peu de temps après, ils ont changé leur esprit et avisé que la coutume des exceptions doivent dériver de la base de la classe Exception. Voir les Meilleures Pratiques pour la gestion des Exceptions sur MSDN.

L'un des plus largement diffusé raisons à cela vient d'un extrait du Jeffery Richter dans le Cadre des lignes Directrices de Conception:

Système.ApplicationException est une classe qui ne doit pas être de la partie .NET Framework. L'idée de départ était que les classes dérivées de SystemException indiquerait les exceptions levées à partir du CLR (ou système) lui-même, tandis que les non-CLR exceptions seraient issues de ApplicationException. Cependant, beaucoup de classes d'exception n'a pas suivi cette tendance. Par exemple, TargetInvocationException (qui est générée par le CLR) est dérivé de ApplicationException. Ainsi, la ApplicationException classe perdu tout sens. La raison de dériver de cette classe de base est de permettre à certains de code plus haut dans la pile d'appel pour attraper la classe de base. Il n'était plus possible d'attraper toutes les exceptions de l'application.

Donc là vous l'avez. Le résumé est que ApplicationException n'est pas nocif, juste inutile.

Answer 2

Selon les remarques dans msdn:

Les applications de l'utilisateur, pas le common language runtime, jeter personnalisé exceptions dérivées de la ApplicationException classe. Le ApplicationException classe établit une distinction entre les exceptions définies par les applications plutôt que des exceptions définies par le système.

Si vous êtes à la conception d'une application qui a besoin de créer ses propres exceptions, il vous est conseillé de tirer personnalisé exceptions de la classe Exception. Il a été à l'origine pensé que la coutume exceptions doivent dériver de la ApplicationException classe; toutefois, dans la pratique, cela n'a pas été trouvé d'ajouter beaucoup de valeur. Pour plus d'informations, reportez-vous aux bonnes Pratiques pour la gestion des Exceptions.

Déduire Exception. Aussi, je ne vois pas le problème avec la création de nouvelles exceptions pour votre cas, tant que c'est justifié. Si vous rencontrez un cas où il y a déjà une exception dans le cadre, utilisez-le, sinon, passez votre propre.

Answer 3

Dans la conception initiale, sous .NET 1.0, il est prévu que le cadre se lèvera et dérivés ; tandis que les applications utilisateur - lève et dérivées.

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

Donc dériver de `` .