Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite 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.
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 OpenFile méthode ne peut pas retourner un handle de fichier ouvert à l’appelant, elle est considérée comme un échec d’exécution.
La plupart des développeurs sont devenus à l’aise avec l’utilisation d’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 frameworks.
✔️ Signalez les échecs d’exécution en lève 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 de framework 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 de Tester-Doer peut avoir une surcharge de performances inacceptable. Dans ce cas, le modèle Try-Parse 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 violation 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’avez pas de membres publics qui peuvent lever ou non en fonction d’une option.
❌ N’avez 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 inline.
❌ Ne lèvez 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 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.