Événements
Créer des applications intelligentes
17 mars, 23 h - 21 mars, 23 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenantCe navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
Propriété | Value |
---|---|
Identificateur de la règle | CA1065 |
Titre | Ne pas lever d'exceptions dans les emplacements inattendus |
Catégorie | Conception |
Le correctif est cassant ou non cassant | Sans rupture |
Activée par défaut dans .NET 9 | Non |
Une méthode dont l'objet n'est pas de lever des exceptions lève une exception.
Les méthodes qui ne sont pas censées lever des exceptions peuvent être catégorisées comme suit :
Ces méthode sont détaillées dans les sections suivantes.
Les propriétés sont essentiellement des champs intelligents. Par conséquent, elles doivent se comporter comme des champs dans la mesure du possible. Les champs ne lèvent pas d’exceptions et les propriétés ne doivent pas non plus en lever. Si une propriété lève une exception, envisagez de la transformer en méthode.
Les exceptions suivantes peuvent être levées à partir d’une méthode Get de propriété :
Les accesseurs d’événements doivent être des opérations simples qui ne lèvent pas d’exceptions. Un événement ne doit pas lever d’exception quand vous essayez d’ajouter ou de supprimer un gestionnaire d’événements.
Les exceptions suivantes peuvent être levées à partir d’un accesseur d’événement :
Les méthodes Equals suivantes ne doivent pas lever d’exceptions :
Une Equals
méthode doit retourner true
ou false
au lieu de lever une exception. Par exemple, s’il Equals
est passé deux types incompatibles, il doit simplement retourner false
au lieu de lever un ArgumentException.
Les méthodes suivantes GetHashCode
ne doivent généralement pas lever d’exceptions :
GetHashCode
doit toujours retourner une valeur. Dans le cas contraire, vous pouvez perdre des éléments dans la table de hachage.
Les versions de GetHashCode
cette prise d’argument peuvent lever un ArgumentException. Toutefois, Object.GetHashCode
ne doit jamais lever d’exception.
Le débogueur utilise System.Object.ToString pour permettre d’afficher des informations sur les objets au format de chaîne. Par conséquent, ToString
ne doit pas changer l’état d’un objet et ne doit pas lever d’exceptions.
Si des exceptions sont levées à partir d’un constructeur statique, le type devient inutilisable dans le domaine d’application actuel. Vous devez avoir une bonne raison (par exemple un problème de sécurité) pour lever une exception à partir d’un constructeur statique.
Si une exception est levée à partir d’un finaliseur, cela entraîne le Fail-fast du CLR, ce qui met fin au processus. Par conséquent, évitez de lever des exceptions dans un finaliseur.
Une méthode System.IDisposable.Dispose ne doit pas lever d’exception. Dispose
est souvent appelé dans le cadre de la logique de nettoyage dans une finally
clause. Par conséquent, la levée explicite d’une exception Dispose
force l’utilisateur à ajouter la gestion des exceptions à l’intérieur de la finally
clause.
Le Dispose(false)
chemin du code ne doit jamais lever d’exceptions, car Dispose
il est presque toujours appelé à partir d’un finaliseur.
Comme Equals
les méthodes, les opérateurs d’égalité doivent retourner ou true
false
, et ne doivent pas lever d’exceptions.
Étant donné que l’utilisateur ignore souvent qu’un opérateur de cast implicite a été appelé, une exception levée par l’opérateur de cast implicite est inattendue. Par conséquent, aucune exception ne doit être levée à partir des opérateurs de cast implicites.
Pour les méthodes getters de propriétés, modifiez la logique pour qu’elle ne lève plus d’exception, ou modifiez la propriété en la transformant en méthode.
Pour tous les autres types de méthode répertoriés précédemment, modifiez la logique afin qu’elle n’ait plus à lever d’exception.
Si la violation a été entraînée par une déclaration d’exception au lieu d’une exception levée, vous pouvez supprimer un avertissement de cette règle en toute sécurité.
Si vous voulez supprimer une seule violation, ajoutez des directives de préprocesseur à votre fichier source pour désactiver et réactiver la règle.
#pragma warning disable CA1065
// The code that's violating the rule is on this line.
#pragma warning restore CA1065
Pour désactiver la règle sur un fichier, un dossier ou un projet, définissez sa gravité sur none
dans le fichier de configuration.
[*.{cs,vb}]
dotnet_diagnostic.CA1065.severity = none
Pour plus d’informations, consultez Comment supprimer les avertissements de l’analyse de code.
Commentaires sur .NET
.NET est un projet open source. Sélectionnez un lien pour fournir des commentaires :
Événements
Créer des applications intelligentes
17 mars, 23 h - 21 mars, 23 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenant