Levée d'exceptions
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 sur cette page peuvent être obsolètes.
Les instructions de levée d’exceptions décrites dans cette section nécessitent une bonne définition de la signification de l’échec d’exécution. L’échec d’exécution se produit chaque fois qu’un membre ne peut pas faire ce qu’il a été conçu pour faire (ce que le nom du membre implique). Par exemple, si la méthode OpenFile ne peut pas retourner un descripteur de fichier ouvert à l’appelant, elle est considérée comme un échec d’exécution.
La plupart des développeurs ont pris l’habitude d’utiliser des exceptions pour les erreurs d’utilisation, telles que la division par zéro ou des références Null. Dans l’infrastructure, les exceptions sont utilisées pour toutes les conditions d’erreur, y compris les erreurs d’exécution.
❌ NE RETOURNEZ PAS de codes d’erreur.
Les exceptions sont les principaux moyens de signaler des erreurs dans les infrastructures.
✔️ SIGNALEZ les échecs d’exécution en levant des exceptions.
✔️ ENVISAGEZ de mettre fin au processus en appelant System.Environment.FailFast (fonctionnalité .NET Framework 2.0) au lieu de lever une exception si votre code rencontre une situation où il est dangereux pour une exécution ultérieure.
❌ N’utilisez PAS d’exceptions pour le flux normal de contrôle, si possible.
À l’exception des défaillances système et des opérations avec des conditions de concurrence potentielles, les concepteurs d’infrastructure doivent concevoir des API afin que les utilisateurs puissent écrire du code qui ne lève pas d’exceptions. Par exemple, vous pouvez fournir un moyen de vérifier les conditions préalables avant d’appeler un membre afin que les utilisateurs puissent écrire du code qui ne lève pas d’exceptions.
Le membre utilisé pour vérifier les conditions préalables d’un autre membre est souvent appelé testeur, et le membre qui effectue réellement le travail est appelé un « Doer ».
Il existe des cas où le modèle Testeur-Doer peut avoir une surcharge de performances inacceptable. Dans ce cas, le modèle essayer-analyser doit être pris en compte (consultez Exceptions et performances pour plus d’informations).
✔️ TENEZ COMPTE des implications en matière de performances de levée d’exceptions. Les taux de levée supérieurs à 100 par seconde sont susceptibles d’avoir un impact notable sur les performances de la plupart des applications.
✔️ DOCUMENTEZ toutes les exceptions levées par des membres pouvant être appelées publiquement en raison d’une infraction du contrat membre (plutôt qu’une défaillance système) et traitez-les dans le cadre de votre contrat.
Les exceptions qui font partie du contrat ne doivent pas passer d’une version à l’autre (par exemple, le type d’exception ne doit pas changer et les nouvelles exceptions ne doivent pas être ajoutées).
❌ N’AYEZ PAS de membres publics qui peuvent lever ou non en fonction d’une option.
❌ N’AYEZ PAS de membres publics qui retournent des exceptions en tant que valeur de retour ou paramètre out.
Le renvoi d’exceptions à partir d’API publiques au lieu de les lever défait la plupart des avantages du rapport d’erreurs basé sur des exceptions.
✔️ ENVISAGEZ d’utiliser des méthodes de générateur d’exceptions.
Il est courant de lever la même exception à partir de différents endroits. Pour éviter le ballonnement du code, utilisez des méthodes d’assistance qui créent des exceptions et initialisent leurs propriétés.
En outre, les membres qui lèvent des exceptions ne sont pas inclus. Le déplacement de l’instruction throw à l’intérieur du générateur peut permettre au membre d’être inclus.
❌ NE LEVEZ PAS d’exceptions à partir de blocs de filtre d’exception.
Lorsqu’un filtre d’exception déclenche une exception, l’exception est interceptée par le CLR et le filtre retourne false. Ce comportement est indistinguishable du filtre qui s’exécute et retourne false explicitement et est donc très difficile à déboguer.
❌ ÉVITEZ de lever explicitement des exceptions à partir de blocs finals. Les exceptions levées implicitement résultant des méthodes appelantes qui lèvent sont acceptables.
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.