CA1065: No producir excepciones en ubicaciones inesperadas
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 9 | 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:
- System.InvalidOperationException y todos los derivados (incluido System.ObjectDisposedException)
- System.NotSupportedException y todos los derivados
- System.ArgumentException (solo a partir del get indizado)
- System.Collections.Generic.KeyNotFoundException (solo a partir del get indizado)
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:
- System.InvalidOperationException y todos los derivados (incluido System.ObjectDisposedException)
- System.NotSupportedException y todos los derivados
- System.ArgumentException y los derivados
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 true
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, 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.