Lançamento de exceções
Nota
Este conteúdo é reimpresso com permissão da Pearson Education, Inc., a partir 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 revisto na terceira edição. Algumas das informações nesta página podem estar desatualizadas.
As diretrizes de lançamento de exceções descritas nesta seção exigem uma boa definição do significado de 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 OpenFile método não puder retornar um identificador de arquivo aberto para o chamador, isso será considerado uma falha de execução.
A maioria dos desenvolvedores se sentiu confortável com o uso de exceções para erros de uso, como divisão por zero ou referências nulas. Na Estrutura, 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.
As exceções são o principal meio de comunicação de erros nos enquadramentos.
✔️ DO relata falhas de execução lançando exceções.
✔️ CONSIDERE encerrar o processo chamando System.Environment.FailFast (recurso do .NET Framework 2.0) em vez de lançar uma exceção se o código encontrar uma situação em que não seja seguro para execução posterior.
❌ NÃO use exceções para o fluxo normal de controle, se possível.
Exceto para falhas do sistema e operações com possíveis condições de corrida, os designers de estrutura devem projetar APIs para que os usuários possam escrever código que não gere exceções. Por exemplo, você pode fornecer uma maneira de verificar as 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 as pré-condições de outro membro é muitas vezes referido como um testador, e o membro que realmente faz o trabalho é chamado de fazedor.
Há casos em que o Tester-Doer Pattern pode ter uma sobrecarga de desempenho inaceitável. Nesses casos, o chamado Try-Parse Pattern deve ser considerado (consulte Exceções e desempenho para obter mais informações).
✔️ CONSIDERE as implicações de desempenho do lançamento de exceções. É provável que taxas de lançamento acima de 100 por segundo afetem visivelmente o desempenho da maioria dos aplicativos.
✔️ DOCUMENTE todas as exceções lançadas 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 do seu contrato.
As exceções que fazem parte do contrato não devem mudar de uma versão para outra (ou seja, o tipo de exceção não deve ser alterado e novas exceções não devem ser adicionadas).
❌ NÃO tenha membros públicos que possam lançar ou não com base em alguma opção.
❌ NÃO tem membros públicos que retornem exceções como o valor de retorno ou um out parâmetro.
Retornar exceções de APIs públicas em vez de lançá-las derrota muitos dos benefícios do relatório de erros baseado em exceções.
✔️ CONSIDERE o uso de métodos de construtor de exceções.
É comum lançar a mesma exceção de lugares diferentes. Para evitar o inchaço do código, use métodos auxiliares que criam exceções e inicializam suas propriedades.
Além disso, os membros que lançam exceções não estão sendo alinhados. Mover a instrução throw dentro do construtor pode permitir que o membro seja embutido.
❌ NÃO lance 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 que executa e retorna false explicitamente e, portanto, é muito difícil de depurar.
❌ EVITE explicitamente lançar exceções de bloqueios finais. Exceções implicitamente lançadas resultantes de métodos de chamada que lançam são aceitáveis.
© Partes 2005, 2009 Microsoft Corporation. Todos os direitos reservados.
Reimpresso com permissão da Pearson Education, Inc., de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 por Addison-Wesley Professional como parte da Microsoft Windows Development Series.