CA1065 : Ne pas lever d'exceptions dans les emplacements inattendus

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é par défaut dans .NET 8 Non

Cause

Une méthode dont l'objet n'est pas de lever des exceptions lève une exception.

Description de la règle

Les méthodes qui ne sont pas censées lever des exceptions peuvent être catégorisées comme suit :

  • Méthodes get de propriété
  • Méthodes d’accesseur d’événements
  • Méthodes equals
  • Méthodes GetHashCode
  • Méthodes ToString
  • Constructeurs statiques
  • Finaliseurs
  • Méthodes De suppression
  • Opérateurs d'égalité
  • Opérateurs de cast implicites

Ces méthode sont détaillées dans les sections suivantes.

Méthodes get de propriété

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é :

Méthodes d’accesseur d’événements

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 :

Méthodes equals

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.

Méthodes GetHashCode

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.

Méthodes ToString

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.

Constructeurs statiques

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.

Finaliseurs

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.

Méthodes De suppression

Une méthode System.IDisposable.Dispose ne doit pas lever d’exception. Disposeest souvent appelé dans le cadre de la logique de propre up 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.

Opérateurs d’égalité (==, !=)

Comme Equals les méthodes, les opérateurs d’égalité doivent retourner ou truefalse, et ne doivent pas lever d’exceptions.

Opérateurs de cast implicites

É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.

Comment corriger les violations

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.

Quand supprimer les avertissements

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é.

Supprimer un avertissement

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.

Voir aussi