Utilisation de types d'exceptions standard
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. à partir des Instructions de conception d’une infrastructure : conventions, idiomes et modèles des bibliothèques réutilisables .NET, 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 en détail les exceptions standard fournies par le Framework et leur utilisation. La liste n’est en aucun cas exhaustive. Concernant l’utilisation d’autres types d’exceptions Framework, consultez la documentation de référence de .NET Framework.
Exception et SystemException
❌ À NE PAS FAIRE : lever System.Exception ou System.SystemException.
❌ À NE PAS FAIRE : intercepter System.Exception ou System.SystemException dans le code du Framework, à moins que vous n’ayez l’intention de les lever à nouveau.
❌ À ÉVITER : intercepter System.Exception ou System.SystemException, sauf dans les gestionnaires d’exceptions de niveau supérieur.
ApplicationException
❌ À NE PAS FAIRE : lever ou dériver de ApplicationException.
InvalidOperationException
✔️ À FAIRE : lever une InvalidOperationException si l’objet se trouve dans un état inapproprié.
ArgumentException, ArgumentNullException et ArgumentOutOfRangeException
✔️ À FAIRE : lever ArgumentException ou l’un de ses sous-types si des arguments incorrects sont passés à un membre. Préférer le type d’exception le plus dérivé, le cas échéant.
✔️ À FAIRE : définir la propriété ParamName au moment de lever 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 qu’elle peut être définie à l’aide de l’une des surcharges de constructeur.
✔️ À FAIRE : utiliser value comme nom du paramètre de valeur implicite des setters de propriétés.
NullReferenceException, IndexOutOfRangeException et AccessViolationException
❌ À NE PAS FAIRE : autoriser les API pouvant être appelées publiquement à lever explicitement ou implicitement NullReferenceException, AccessViolationException ou IndexOutOfRangeException. Ces exceptions sont réservées et levées par le moteur d’exécution. Dans la plupart des cas, elles indiquent un bogue.
Effectuez une vérification des arguments pour éviter de lever ces exceptions, car cela exposerait des données d’implémentation de votre méthode, susceptibles changer au fil du temps.
StackOverflowException
❌ À NE PAS FAIRE : lever StackOverflowException explicitement. Cette exception ne doit être levée explicitement que par l’infrastructure CLR.
❌ À NE PAS FAIRE : intercepter StackOverflowException.
Il est presque impossible d’écrire du code managé qui reste cohérent en présence de dépassements de la capacité de la pile arbitraires. Les parties non managées du CLR conservent leur cohérence en utilisant des probes pour déplacer les dépassements de la capacité de la pile vers des endroits bien définis plutôt qu’en se retirant des dépassements arbitraires.
OutOfMemoryException
❌ À NE PAS FAIRE : lever OutOfMemoryException explicitement. Cette exception ne doit être levée explicitement que par l’infrastructure CLR.
ComException, SEHException et ExecutionEngineException
❌ À NE PAS FAIRE : lever explicitement COMException, ExecutionEngineException ou SEHException. Ces exceptions ne doivent être levées que par l’infrastructure CLR.
Portions © 2005, 2009 Microsoft Corporation. Tous droits réservés.
Réimprimé avec l’autorisation de Pearson Education, Inc. et extrait de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la série sur le développement Microsoft Windows.