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

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 conversão implícita

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 comportar-se como um campo de dados sempre que possível. Os campos não lançam exceções e as propriedades também não. Se tiveres uma propriedade que lance uma exceção, considera torná-la um método.

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

• System.InvalidOperationException e todos os derivados (incluindo System.ObjectDisposedException)
• System.NotSupportedException e todos os derivados
• System.ArgumentException (somente a partir de get indexado)
• System.Collections.Generic.KeyNotFoundException (somente a partir de get indexado)

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 a partir de um acessório de evento:

• System.InvalidOperationException e todos os derivados (incluindo System.ObjectDisposedException)
• System.NotSupportedException e todos os derivados
• System.ArgumentException e derivados

Métodos iguais

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

• System.Object.Equals
• System.IEquatable<T>.Equals

Um Equals método deve retornar true ou false em vez de lançar uma exceção. Por exemplo, se forem passados dois tipos incompatíveis a Equals, deve simplesmente retornar false em vez de gerar um ArgumentException.

Métodos GetHashCode

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

• System.Object.GetHashCode
• System.Collections.IEqualityComparer.GetHashCode

GetHashCode deve sempre devolver um valor. Caso contrário, podem-se perder itens na tabela de hash.

As versões de GetHashCode que aceitam um 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 numa cláusula finally. Portanto, lançar explicitamente uma exceção de Dispose obriga o utilizador a adicionar tratamento de exceções dentro da cláusula finally.

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

Operadores de igualdade (==, !=)

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

Operadores de conversão implícita

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 conversão implícitos.

Como corrigir violações

Para os getters das propriedades, modifique a lógica para que não precise mais lançar uma exceção ou transforme a propriedade num 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 definição de exceção em vez de uma exceção lançada, é seguro suprimir um aviso desta 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.

Regras conexas

• CA2219: Não levante exceções em cláusulas de exceção

Consulte também

• Regras de conceção