Share via

CA1065: Não acionar exceções em locais inesperados

  • Artigo
Property Valor
ID da regra CA1065
Título Não acionar exceções em locais inesperados
Categoria Projetar
Correção interruptiva ou sem interrupção Sem interrupção
Habilitado por padrão no .NET 8 Não

Causa

Um método que não deve acionar exceções aciona uma exceção.

Descrição da regra

Métodos que não devem gerar exceções podem ser categorizados da seguinte maneira:

  • Métodos de obtenção de propriedade
  • Métodos de acessador de eventos
  • Métodos Equals
  • Métodos GetHashCode
  • Métodos ToString
  • Construtores estáticos
  • Finalizadores
  • Métodos de descarte
  • Operadores de igualdade
  • Operadores de elenco implícitos

As seções a seguir discutem esses tipos de métodos.

Métodos de obtenção de propriedade

As propriedades são basicamente campos inteligentes. Portanto, elas devem se comportar como um campo tanto quanto possível. Os campos não geram exceções e nem as propriedades deveriam. Se você tiver uma propriedade que gera uma exceção, considere torná-la um método.

As seguintes exceções podem ser geradas de um método get de propriedade:

Métodos de acessador de eventos

Os acessadores de eventos devem ser operações simples que não geram exceções. Um evento não deve gerar uma exceção quando você tentar adicionar ou remover um manipulador de eventos.

As seguintes exceções podem ser geradas de um acessador de eventos:

Métodos Equals

Os seguintes métodos Equals não devem gerar exceções:

Um Equals método deve retornar true ou false em vez de lançar uma exceção. Por exemplo, se Equals for passado dois tipos incompatíveis, ele deve apenas retornar false em vez de lançar um ArgumentExceptionarquivo .

Métodos GetHashCode

Os seguintes GetHashCode métodos geralmente não devem lançar exceções:

GetHashCode deve sempre retornar um valor. Caso contrário, você pode perder itens na tabela de hash.

As versões GetHashCode que levam um argumento podem lançar um ArgumentExceptionarquivo . No entanto, Object.GetHashCode nunca deve lançar uma exceção.

Métodos ToString

O depurador usa System.Object.ToString para ajudar a exibir informações sobre objetos no formato de cadeia de caracteres. Portanto, ToString não deve alterar o estado de um objeto e não deve lançar exceções.

Construtores estáticos

Gerar exceções de um construtor estático faz com que o tipo seja inutilizável no domínio do aplicativo atual. Você deve ter um bom motivo (como um problema de segurança) para gerar uma exceção de um construtor estático.

Finalizadores

Gerar uma exceção de um finalizador faz com que o CLR falhe rapidamente, o que desmonta o processo. Portanto, evite lançar exceções em um finalizador.

Métodos de descarte

Um método System.IDisposable.Dispose não deve gerar uma exceção. Dispose é frequentemente chamado como parte da lógica de limpeza em uma finally cláusula. Portanto, lançar explicitamente uma exceção de força o usuário a adicionar manipulação de Dispose exceção dentro da finally cláusula.

O Dispose(false) caminho do código nunca deve lançar exceções, porque Dispose quase sempre é chamado de um finalizador.

Operadores de igualdade (==, !=)

Assim como Equals os métodos, os operadores de igualdade devem retornar ou truefalse, e não devem lançar exceções.

Operadores de elenco implícitos

Como o usuário geralmente não sabe que um operador de conversão implícita foi chamado, uma exceção gerada pelo operador de conversão implícita é inesperada. Portanto, nenhuma exceção deve ser gerada de operadores de conversão implícita.

Como corrigir violações

Para getters de propriedade, altere a lógica para que ela não precise mais lançar uma exceção ou altere a propriedade em um método.

Para todos os outros tipos de método listados anteriormente, altere a lógica para que ela não precise mais gerar uma exceção.

Quando suprimir avisos

Se a violação foi causada por uma declaração de exceção em vez de uma exceção gerada, é seguro suprimir um aviso dessa regra.

Suprimir um aviso

Para suprimir apenas uma violação, adicione diretivas de pré-processador ao arquivo de origem a fim de desabilitar e, em seguida, reabilitar a regra.

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

Para desabilitar a regra em um arquivo, uma pasta ou um projeto, defina a severidade como none no arquivo de configuração.

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

Para obter mais informações, confira Como suprimir avisos de análise de código.

Confira também