CA1065: No producir excepciones en ubicaciones inesperadas

  • Artículo
Propiedad Value
Identificador de la regla CA1065
Título No producir excepciones en ubicaciones inesperadas
Categoría Diseño
La corrección es problemática o no problemática Poco problemático
Habilitado de forma predeterminada en .NET 8 No

Causa

Un método que no se espera que produzca excepciones inicia una excepción.

Descripción de la regla

Los métodos que no se espera que produzcan excepciones se pueden categorizar de la manera siguiente:

  • Métodos get de propiedades
  • Métodos de descriptor de acceso de eventos
  • Métodos iguales
  • Métodos GetHashCode
  • Métodos ToString
  • Constructores estáticos
  • Finalizadores
  • Métodos Dispose
  • Operadores de igualdad
  • Operadores de conversión implícitos

En las secciones siguientes se describen estos tipos de métodos.

Métodos get de propiedades

Las propiedades son básicamente campos inteligentes. Por lo tanto, deben comportarse como un campo en la medida de lo posible. Los campos no producen excepciones y las propiedades tampoco deberían. Si tiene una propiedad que produce una excepción, considere la posibilidad de convertirla en un método.

A partir de un método get de propiedad, se pueden producir las siguientes excepciones:

Métodos de descriptor de acceso de eventos

Los descriptores de acceso de eventos deben ser operaciones simples que no produzcan excepciones. Un evento no debe producir una excepción al intentar agregar o quitar un controlador de eventos.

A partir de un descriptor de acceso de eventos, se pueden producir las siguientes excepciones:

Métodos iguales

Los siguientes métodos Equals no deben producir excepciones:

Un Equals método debe devolver true o false en lugar de producir una excepción. Por ejemplo, si Equals se pasan dos tipos no coincidente, solo debe devolverse false en lugar de iniciar un ArgumentException.

Métodos GetHashCode

Normalmente, los métodos siguientes GetHashCode no deben producir excepciones:

GetHashCode siempre debe devolver un valor. De lo contrario, puede perder elementos en la tabla hash.

Las versiones de GetHashCode que toman un argumento pueden producir un ArgumentException. Sin embargo, Object.GetHashCode nunca debe iniciar una excepción.

Métodos ToString

El depurador usa System.Object.ToString para ayudar a mostrar información sobre los objetos en formato de cadena. Por lo tanto, ToString no debe cambiar el estado de un objeto y no debe producir excepciones.

Constructores estáticos

Producir excepciones a partir de un constructor estático hace que el tipo sea inutilizable en el dominio de aplicación actual. Debe tener una buena razón (por ejemplo, un problema de seguridad) para producir una excepción a partir de un constructor estático.

Finalizadores

Producir una excepción a partir de un finalizador hace que CLR fracase rápido, lo que anula el proceso. Por lo tanto, evite iniciar excepciones en un finalizador.

Métodos Dispose

Un método System.IDisposable.Dispose no debe producir una excepción. Dispose a menudo se llama como parte de la lógica de limpieza en una finally cláusula . Por lo tanto, al iniciar explícitamente una excepción, Dispose el usuario obliga al usuario a agregar el control de excepciones dentro de la finally cláusula .

La Dispose(false) ruta de acceso del código nunca debe iniciar excepciones, ya que Dispose casi siempre se llama desde un finalizador.

Operadores de igualdad (==, !=)

Al igual que Equals los métodos, los operadores de igualdad deben devolver o truefalse, y no deben producir excepciones.

Operadores de conversión implícitos

Dado que el usuario a menudo no es consciente de que se ha llamado a un operador de conversión implícito, no cabe esperar una excepción producida por el operador de conversión implícito. Por lo tanto, no se debe producir ninguna excepción a partir de los operadores de conversión implícitos.

Cómo corregir infracciones

En el caso de los captadores de propiedades, cambie la lógica para que ya no tenga que producir una excepción, o bien cambie la propiedad a un método.

En el caso de todos los demás tipos de método enumerados anteriormente, cambie la lógica para que ya no tenga que producir una excepción.

Cuándo suprimir las advertencias

Si la infracción se debió a una declaración de excepción en lugar de a una excepción producida, es seguro suprimir una advertencia de esta regla.

Supresión de una advertencia

Si solo quiere suprimir una única infracción, agregue directivas de preprocesador al archivo de origen para deshabilitar y volver a habilitar la regla.

#pragma warning disable CA1065
// The code that's violating the rule is on this line.
#pragma warning restore CA1065

Para deshabilitar la regla de un archivo, una carpeta o un proyecto, establezca su gravedad en none del archivo de configuración.

[*.{cs,vb}]
dotnet_diagnostic.CA1065.severity = none

Para obtener más información, consulte Procedimiento para suprimir advertencias de análisis de código.

Consulte también