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

TypeName

DoNotRaiseExceptionsInUnexpectedLocations

CheckId

CA1065

<strong>Categoria</strong>

Microsoft.design

Alteração significativa

Não separável

Causa

Um método que não é esperado para lançar exceções lança uma exceção.

Descrição da regra

Métodos não são esperados para lançar exceções podem ser categorizados como segue:

  • Métodos Get de propriedade

  • Métodos de assessor de evento

  • Métodos Equals

  • Métodos GetHashCode

  • Métodos ToString

  • Construtores estáticos

  • Finalizadores

  • Métodos de Dispose

  • Operadores de igualdade

  • Operadores de conversão implícita

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

Métodos Get de propriedade

Propriedades são campos basicamente inteligentes. Portanto, eles devem se comportar como um campo tanto quanto possível. Campos não lançar exceções e nem devem propriedades. Se você tiver uma propriedade que lança uma exceção, considere a possibilidade de torná-lo um método.

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

Métodos de assessor de evento

Acessadores de evento devem ser operações simples, não lançar exceções. Um evento não deve lançar uma exceção ao tentar adicionar ou remover um manipulador de eventos.

As seguintes exceções podem ser geradas de um evento accesor:

Métodos Equals

O seguinte é igual a métodos não devem lançar exceções:

Um é igual a método deve retornar true ou false em vez de gerar uma exceção. Por exemplo, se é igual a é passado dois tipos incompatíveis ele deverá apenas retornar false em vez de gerar uma ArgumentException.

Métodos GetHashCode

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

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

As versões do GetHashCode que o levam um argumento pode lançar uma ArgumentException. No entanto, Object.GetHashCode nunca deve acionar uma exceção.

Métodos ToString

O depurador usa Object.ToString para ajudar a exibir informações sobre objetos em formato de seqüência de caracteres. Portanto, ToString não deve alterar o estado de um objeto e ele não deve lançar exceções.

Construtores estáticos

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

Finalizadores

Lançando uma exceção de um finalizador faz com que o CLR falhe rápido, que destrói o processo. Portanto, gerar exceções em um finalizador deve sempre ser evitada.

Métodos de Dispose

A IDisposable.Dispose método não deve lançar uma exceção. Costuma ser chamada de Dispose como parte da lógica de limpeza uma finally cláusula. Portanto, explicitamente, lançando uma exceção de Dispose força o usuário adicione dentro de manipulação de exceção de finally cláusula.

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

Operadores de igualdade (= =,! =)

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

Operadores de conversão implícita

Como o usuário costumam ser desconhece chamado de um operador de conversão implícita, uma exceção lançada pelo operador cast implícita é completamente inesperada. Portanto, sem exceções devem ser lançadas de operadores de conversão implícita.

Como corrigir violações

Para getters de propriedade, ou alterar a lógica para que ele não tem mais lançar uma exceção ou alterar a propriedade para um método.

Para todos os outros método tipos listados anteriormente, altere a lógica para que ele não deve lançar uma exceção.

Quando suprimir avisos

É seguro eliminar um aviso esta regra se a violação tiver sido causada por uma declaração em vez de uma exceção gerada uma exceção.

Regras relacionadas

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

Consulte também

Outros recursos

Avisos de design