Quelles exceptions intégrées à .NET puis-je lancer depuis mon application ?

Question

Si j'ai besoin de lancer une exception à partir de mon application, quelles classes d'exception .NET intégrées puis-je utiliser ? Sont-elles toutes acceptables ? Quand dois-je créer mes propres classes ?

Answer 1

Voir Création et de lever des Exceptions.

De lancer des exceptions intégrées, il dit:

"Ne jetez pas de Système.Exception, Système.SystemException, Système.NullReferenceException, ou d'un Système.IndexOutOfRangeException intentionnellement à partir de votre propre code source."

et

"Ne Jetez Pas Les Exceptions Générales

Si vous jetez un général type d'exception, comme l'Exception ou SystemException dans une bibliothèque ou d'un cadre, il force les consommateurs à attraper toutes les exceptions, y compris les exceptions inconnues, qu'ils ne savent pas comment gérer.

Au lieu de cela, jetez un plus type dérivé qui existe déjà dans le cadre, ou créer votre propre type qui dérive de l'Exception."

Cette entrée de blog a aussi quelques lignes directrices utiles.

Aussi, FxCop d'analyse de code définit une liste de "ne pas soulever des exceptions" comme décrit ici. Il recommande:

"L'exception suivante types sont trop générales pour fournir suffisamment d'informations pour l'utilisateur:

• Système.Exception

• Système.ApplicationException

• Système.SystemException

L'exception suivante types sont réservés et doivent être levées que par le common language runtime:

• Système.ExecutionEngineException

• Système.IndexOutOfRangeException

• Système.NullReferenceException

• Système.OutOfMemoryException

Donc, en théorie, vous pouvez augmenter n'importe quel autre framework type d'exception, vous permettant de bien comprendre le but de l'exception, comme décrit par Microsoft (voir la documentation MSDN).

Remarque, ce sont des "lignes directrices" et comme certains l'ont dit, il y a un débat autour du Système.IndexOutOfRangeException (c'est à dire beaucoup de développeurs de lever cette exception).

Answer 2

Au sujet de System.Exception y System.ApplicationException : Cette dernière était destinée à être utilisée comme classe de base de toutes les exceptions personnalisées. Cependant, cela n'a pas été appliqué de manière cohérente depuis le début. Par conséquent, il y a une controverse sur la question de savoir si cette classe devrait être utilisée plutôt que d'utiliser la classe System.Exception comme classe de base pour toutes les exceptions.

Quelle que soit la façon dont vous décidez, jamais lancer directement une instance de ces deux classes. C'est d'ailleurs dommage qu'elles ne soient pas abstact . Pour ce que cela vaut, essayez toujours d'utiliser l'exception la plus spécifique possible. S'il n'en existe aucune qui réponde à votre besoin, n'hésitez pas à en créer une. Dans ce cas, cependant, veillez à ce que votre exception présente un avantage par rapport aux exceptions existantes. En particulier, elle doit véhiculer parfaitement son sens et fournir toutes les informations nécessaires pour traiter la situation de manière pertinente.

Évitez de créer des exceptions fictives qui ne font rien de significatif. Dans la même veine, évitez de créer d'énormes hiérarchies de classes d'exceptions, elles sont rarement utiles (bien que je puisse imaginer une ou deux situations où je les utiliserais un analyseur syntaxique étant l'une d'entre elles).

Answer 3

J'utilise le ArgumentException (et ses "amis") régulièrement.

NotSupportedException y NotImplementedException sont également fréquents.

Answer 4

Mon conseil serait de vous concentrer sur deux choses :

1. Scénarios
2. Attentes des utilisateurs

En d'autres termes, je m'assiérais et j'identifierais :

1. Dans quels scénarios voulez-vous lancer des exceptions ?
2. Dans ces scénarios, qu'attendent les utilisateurs de votre API ?

La réponse à la question 1 est, bien sûr, spécifique à l'application. La réponse à la question 2 est "ce que fait tout code similaire avec lequel ils sont déjà familiers".

Le comportement qui en découle est :

1. Sous les scénarios qui se présentent dans vos programmes et qui arrivent aussi dans le cadre, tels que des arguments nuls, hors de portée, invalides, des méthodes qui ne sont pas méthodes non implémentées, ou simplement non supportées, vous devez alors utiliser les mêmes exceptions que le framework. Les personnes qui utilisent vos API vont s'attendre à ce qu'elles se comportent ainsi (car c'est ainsi que tout se passe). comportement (parce que c'est ainsi que tout le reste se comporte), et seront donc mieux à même d'utiliser votre API dès le départ.

   2. Pour les nouveaux scénarios qui n'existent pas dans le cadre de travail, vous devriez aller de l'avant et inventer vos propres classes d'exception. Je dirais que vous devriez préférer Exception comme classe de base à moins qu'il n'existe une autre exception de base qui offre les services dont vous avez besoin. D'une manière générale, je ne pense pas que quelque chose comme "ApplicationException" vous aidera beaucoup. beaucoup. Lorsque vous commencez à définir vos propres exceptions, vous devez cependant garder à l'esprit certaines choses. garder à l'esprit :

   a. Le but premier d'une exception est la communication humaine. Elles transmettent des informations sur quelque chose qui s'est produit et qui n'aurait pas dû se produire. Elles doivent fournir suffisamment d'informations pour identifier la cause d'un problème et trouver comment le résoudre. le résoudre.

   b. La cohérence interne est extrêmement importante. Il faut faire en sorte que votre application se comporte de manière aussi universelle que possible. possible dans des circonstances similaires rendra les utilisateurs de votre API plus productifs.

Pour ce qui est des règles strictes sur ce que vous devez faire ou ne pas faire... Je ne m'inquiéterais pas de ce genre de choses. Je me concentrerais plutôt sur l'identification de scénarios, sur la recherche de l'exception existante qui correspond à ces scénarios, puis sur la conception minutieuse de votre propre exception s'il n'en existe pas.

Answer 5

Vous pouvez créer et lancer à peu près n'importe lequel d'entre eux, mais vous ne devriez généralement pas le faire. Par exemple, les diverses exceptions de validation d'argument (ArgumentException, ArgumentNullException, ArgumentOutOfRangeException, etc.) peuvent être utilisées dans le code d'application, mais pas AccessViolationException. ApplicationException est fournie comme classe de base appropriée pour toute classe d'exception personnalisée dont vous pourriez avoir besoin.

Voir ceci Article de MSDN pour une liste des meilleures pratiques - elle fait référence à la gestion des exceptions, mais contient également de bons conseils pour les créer...