Gerar exceções
Observação
Este conteúdo é reimpresso com permissão da Pearson Education, Inc. de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Essa edição foi publicada em 2008 e, desde então, o livro foi totalmente revisado na terceira edição. Algumas das informações nesta página podem estar desatualizadas.
As diretrizes de geração de exceção descritas nesta seção exigem uma boa definição do significado da falha de execução. A falha de execução ocorre sempre que um membro não pode fazer o que foi projetado para fazer (o que o nome do membro implica). Por exemplo, se o método OpenFile não puder retornar um identificador de arquivo aberto ao chamador, ele será considerado uma falha de execução.
A maioria dos desenvolvedores se sente confortável em usar exceções para erros de uso, como divisão por zero ou referências nulas. No Framework, as exceções são usadas para todas as condições de erro, incluindo erros de execução.
❌ NÃO retorne códigos de erro.
Exceções são o principal meio de relatar erros em estruturas.
✔️ RELATE relata falhas de execução gerando exceções.
✔️ CONSIDERE encerrar o processo chamando System.Environment.FailFast (.NET Framework recurso 2.0), em vez de gerar uma exceção, se o código encontrar uma situação em que não seja seguro para execução adicional.
❌ NÃO use exceções para o fluxo normal de controle, se possível.
Exceto por falhas e operações do sistema com possíveis condições de corrida, os designers de estrutura devem criar APIs para que os usuários possam escrever código que não gere exceções. Por exemplo, você pode fornecer um modo de verificar pré-condições antes de chamar um membro para que os usuários possam escrever código que não gere exceções.
O membro usado para verificar pré-condições de outro membro é frequentemente chamado de testador; o membro que realmente faz o trabalho é chamado de executor.
Há casos em que o padrão Testador-Executor pode ter uma sobrecarga de desempenho inaceitável. Nesses casos, o chamado padrão de Try-Parse deve ser considerado (confira Exceções e Desempenho para mais informações).
✔️ CONSIDERE as implicações de desempenho de gerar exceções. As taxas de geração acima de 100 por segundo provavelmente afetarão visivelmente o desempenho da maioria dos aplicativos.
✔️ DOCUMENTE todas as exceções geradas por membros publicamente chamáveis devido a uma violação do contrato de membro (em vez de uma falha do sistema) e trate-as como parte de seu contrato.
As exceções que fazem parte do contrato não devem ser alteradas de uma versão para a próxima (ou seja, o tipo de exceção não deve ser alterado e novas exceções não devem ser adicionadas).
❌ NÃO tem membros públicos que possam gerar ou não com base em alguma opção.
❌ NÃO tenha membros públicos que retornem exceções como o valor retornado ou um parâmetro out.
Retornar exceções de APIs públicas em vez de gerá-las anula muitos dos benefícios do relatório de erros baseado em exceção.
✔️ CONSIDERE usar métodos do construtor de exceções.
É comum gerar a mesma exceção de locais diferentes. Para evitar bloat de código, use métodos auxiliares que criam exceções e inicializam suas propriedades.
Além disso, os membros que geram exceções não estão sendo embutidos. Mover a instrução throw dentro do construtor pode permitir que o membro seja embutido.
❌ NÃO gere exceções de blocos de filtro de exceção.
Quando um filtro de exceção gera uma exceção, a exceção é capturada pelo CLR e o filtro retorna false. Esse comportamento é indistinguível do filtro executando e retornando false explicitamente, portanto, é muito difícil de depurar.
❌ EVITE gerar explicitamente exceções de blocos finally. Exceções geradas implicitamente resultantes de métodos de chamada que geram são aceitáveis.
Portions © 2005, 2009 Microsoft Corporation. Todos os direitos reservados.
Reimpresso com permissão da Pearson Education, Inc. das Diretrizes de Design do Framework: convenções, linguagens e padrões para bibliotecas do .NET reutilizável, 2ª edição por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 por Addison-Wesley Professional como parte da série de desenvolvimento do Microsoft Windows.