Comparteix a través de

CA1065: No producir excepciones en ubicaciones inesperadas

Propiedad Valor
Identificador de la regla CA1065
Título No generen excepciones en ubicaciones inesperadas
Categoría Diseño
La corrección interrumpe o no interrumpe Sin interrupción
Habilitado de forma predeterminada en .NET 10 No
Idiomas aplicables C# y Visual Basic

Causa

Un método que no se espera que produzca excepciones lanza 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 acceso a 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.

Las siguientes excepciones pueden ser lanzadas desde un método get de propiedad:

Métodos de acceso a eventos

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

Las siguientes excepciones pueden ser lanzadas desde un accesor de eventos:

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 a Equals se le pasan dos tipos no coincidentes, debería simplemente devolver false en lugar de lanzar 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 lanzar 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 lanzar una excepción desde un constructor estático.

Finalizadores

Lanzar una excepción desde un finalizador hace que el CLR falle rápidamente, lo que detiene el proceso. Por lo tanto, evite lanzar 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 cláusula finally. Por lo tanto, al arrojar explícitamente una excepción desde Dispose, obliga al usuario a agregar el control de excepciones dentro de la cláusula finally.

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

Operadores de igualdad (==, !=)

Al igual que los métodos Equals, los operadores de igualdad deben devolver ya sea true o false, 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, una excepción generada por el operador de conversión implícito es inesperada. 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

  • Last updated on