Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
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 jeter System.Exception ou System.SystemException.
❌ N'interceptez PAS System.Exception ou System.SystemException dans le code d'infrastructure, sauf si vous envisagez de les relancer.
❌ ÉVITEZ d’intercepter System.Exception ou System.SystemException, sauf dans les gestionnaires d’exceptions de niveau supérieur.
ApplicationException
❌ NE levez PAS ou NE dérivez PAS PAS de ApplicationException.
Exception d'opération invalide
✔️ LEVEZ une exception InvalidOperationException si l’objet est dans un état inapproprié.
ArgumentException, ArgumentNullException et ArgumentOutOfRangeException
✔️ LEVEZ une exception ArgumentException ou l'un de ses sous-types si de mauvais arguments sont passés à un membre. Préférez le type d’exception le plus dérivé, le cas échéant.
✔️ Définissez la propriété ParamName lorsque vous lancez 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.
✔️ UTILISEZ value pour le nom du paramètre de valeur implicite des setters de propriétés.
NullReferenceException, IndexOutOfRangeException et AccessViolationException
❌ NE PAS autoriser les API appelables publiquement à lever explicitement ou implicitement NullReferenceException, AccessViolationException ou 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 levez PAS explicitement StackOverflowException. L’exception doit être levée explicitement uniquement par le CLR.
❌ N'interceptez PAS StackOverflowException.
Il est presque impossible d’écrire du code managé qui reste cohérent en cas de dépassements de la capacité de la pile arbitraires. Les parties non managées du CLR restent cohérentes en utilisant des sondes pour déplacer les dépassements de la capacité de la pile vers des emplacements bien définis, plutôt que d'opérer à partir de dépassements de la capacité de la pile arbitraires.
OutOfMemoryException (exception de mémoire insuffisante)
❌ NE levez PAS explicitement OutOfMemoryException. Cette exception doit être levée uniquement par l’infrastructure CLR.
ComException, SEHException et ExecutionEngineException
❌ NE PAS lancer explicitement COMException, ExecutionEngineException et 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.