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

Propriété Valeur
Identificateur de la règle CA1065
Titre Ne pas lever d'exceptions dans les emplacements inattendus
Catégorie Conception
Le correctif a un effet disruptif ou non disruptif Sans rupture
Activé par défaut dans .NET 10 Non
Langues applicables C# et Visual Basic

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 de récupération 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 de récupération 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 générées par une méthode get de propriété :

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

Les accesseurs d'événements devraient être des opérations simples qui ne génèrent 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 déclenchées par un accesseur d'événement :

Méthodes d'égalité

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, si Equals reçoit deux types incompatibles, il doit simplement retourner false au lieu de générer 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. Sinon, vous pouvez perdre des éléments dans la table de hachage.

Les versions de GetHashCode qui prennent un argument peuvent générer 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 provoque un échec rapide du CLR, entraînant l'arrêt du 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. 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 dans la clause finally.

Le chemin d'exécution du code Dispose(false) ne doit jamais lever d’exceptions, car il est généralement appelé à partir d’un finaliseur Dispose.

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

Comme les méthodes Equals, les opérateurs d’égalité doivent retourner soit true soit false, 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 conversion 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

  • Last updated on