Partager via


Utilisation de types d’exceptions standard

Remarque

Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. tiré de Lignes directrices de conception de framework : Conventions, Idiomes et Modèles pour les bibliothèques .NET réutilisables, 2ème édition. Cette édition a été publiée en 2008, et le livre a été entièrement révisé dans la troisième édition. Certaines informations de cette page peuvent être obsolètes.

Cette section décrit les exceptions standard fournies par l’infrastructure et les détails de leur utilisation. La liste n’est pas exhaustive. Reportez-vous à la documentation de référence du .NET Framework pour l’utilisation d’autres types d’exceptions Framework.

Exception et SystemException

❌ NE PAS lever System.Exception ou System.SystemException.

❌ NE PAS intercepter System.Exception ou System.SystemException dans le code de framework, sauf si vous envisagez de se réactiver.

❌ ÉVITEZ d’intercepter System.Exception ou System.SystemException, sauf dans les gestionnaires d’exceptions de niveau supérieur.

ApplicationException

❌ NE PAS lever ou dériver de ApplicationException.

Exception d'opération invalide

✔️ Lève InvalidOperationException une exception si l’objet est dans un état inapproprié.

ArgumentException, ArgumentNullException et ArgumentOutOfRangeException

✔️ Lèvez ou l’un ArgumentException de ses sous-types si des arguments incorrects sont passés à un membre. Préférez le type d’exception le plus dérivé, le cas échéant.

✔️ Définissez la ParamName propriété lors de la levée de l’une des sous-classes de ArgumentException.

Cette propriété représente le nom du paramètre qui a provoqué la levée de l’exception. Notez que la propriété peut être définie à l’aide de l’une des surcharges du constructeur.

✔️ value Utilisez-la pour le nom du paramètre de valeur implicite des setters de propriétés.

NullReferenceException, IndexOutOfRangeException et AccessViolationException

❌ NE PAS autoriser les API pouvant être appelées publiquement pour lever NullReferenceExceptionexplicitement ou implicitement , AccessViolationExceptionou IndexOutOfRangeException. Ces exceptions sont réservées et levées par le moteur d’exécution et, dans la plupart des cas, indiquent un bogue.

Effectuez la vérification des arguments pour éviter de lever ces exceptions. La levée de ces exceptions expose les détails de l’implémentation de votre méthode qui peuvent changer au fil du temps.

StackOverflowException

❌ NE PAS lever StackOverflowExceptionexplicitement . L’exception doit être levée explicitement uniquement par le CLR.

❌ NE PAS intercepter StackOverflowException.

Il est presque impossible d’écrire du code managé qui reste cohérent en présence de dépassements de pile arbitraires. Les parties non managées du CLR restent cohérentes à l’aide de sondes pour déplacer des dépassements de pile vers des emplacements bien définis plutôt que de se retirer des dépassements de pile arbitraires.

OutOfMemoryException (exception de mémoire insuffisante)

❌ NE PAS lever OutOfMemoryExceptionexplicitement . Cette exception doit être levée uniquement par l’infrastructure CLR.

ComException, SEHException et ExecutionEngineException

❌ NE PAS lever COMExceptionexplicitement , ExecutionEngineExceptionet SEHException. Ces exceptions doivent être levées uniquement par l’infrastructure CLR.

Portions © 2005, 2009 Microsoft Corporation. Tous les droits réservés.

Réimprimé par l’autorisation de Pearson Education, Inc. tiré de Framework Design Guidelines : Conventions, Idioms et Patterns pour les bibliothèques .NET réutilisables, 2e édition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la Série de développement Microsoft Windows.

Voir aussi