Partilhar via

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

  • Artigo
Property valor
ID da regra CA1065
Título Não levante exceções em locais inesperados
Categoria Desenho
A correção está quebrando ou não quebrando Sem quebra
Habilitado por padrão no .NET 8 Não

Motivo

Um método que não se espera que lance exceções lança uma exceção.

Descrição da regra

Os métodos que não devem gerar exceções podem ser categorizados da seguinte forma:

  • Métodos de obtenção de propriedade
  • Métodos de acesso a eventos
  • Métodos iguais
  • Métodos GetHashCode
  • Métodos ToString
  • Construtores estáticos
  • Finalizadores
  • Métodos de eliminação
  • Operadores de igualdade
  • Operadores de fundição implícitos

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

Métodos de obtenção de propriedade

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

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

Métodos de acesso a eventos

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

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

Métodos iguais

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 ArgumentException.

Métodos GetHashCode

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

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

As versões GetHashCode desse argumento podem lançar um ArgumentException. 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 em 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

Lançar 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 lançar uma exceção de um construtor estático.

Finalizadores

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

Métodos de eliminação

Um System.IDisposable.Dispose método não deve lançar 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 tratamento 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 a partir de um finalizador.

Operadores de igualdade (==, !=)

Como Equals os métodos, os operadores de igualdade devem retornar ou true , falsee não devem lançar exceções.

Operadores de fundição implícitos

Como o usuário muitas vezes não sabe que um operador de cast implícito foi chamado, uma exceção lançada pelo operador de cast implícito é inesperada. Portanto, nenhuma exceção deve ser lançada pelos operadores de elenco implícitos.

Como corrigir violações

Para os 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 lançar 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 lançada, é seguro suprimir um aviso dessa regra.

Suprimir um aviso

Se você quiser apenas suprimir uma única violação, adicione diretivas de pré-processador ao seu arquivo de origem para desativar e, em seguida, reativar 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 de um arquivo, pasta ou projeto, defina sua gravidade como none no arquivo de configuração.

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

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

Consulte também