Usar tipos de exceção padrão
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.
Esta seção descreve as exceções padrão fornecidas pelo Framework e os detalhes de seu uso. A lista não está completa de forma alguma. Consulte a documentação de referência do .NET Framework para uso de outros tipos de exceção do Framework.
Exceção e SystemException
❌ NÃO lance System.Exception ou System.SystemException.
❌ NÃO capture System.Exception ou System.SystemException no código da estrutura, a menos que você pretenda relançar.
❌ EVITE capturar System.Exception ou System.SystemException, exceto em manipuladores de exceção de nível superior.
ApplicationException
❌ NÃO lance ou derive de ApplicationException.
InvalidOperationException
✔️ LANCE um InvalidOperationException se o objeto estiver em um estado inadequado.
ArgumentException, ArgumentNullException e ArgumentOutOfRangeException
✔️ LANCE ArgumentException ou um de seus subtipos se argumentos ruins forem passados para um membro. Prefira o tipo de exceção mais derivado, se aplicável.
✔️ DEFINA a propriedade ParamName ao lançar uma das subclasses de ArgumentException.
Esta propriedade representa o nome do parâmetro que fez com que a exceção fosse lançada. Observe que a propriedade pode ser definida usando uma das sobrecargas do construtor.
✔️ USE value para o nome do parâmetro de valor implícito dos setters de propriedade.
NullReferenceException, IndexOutOfRangeException e AccessViolationException
❌ NÃO permita que APIs de chamada pública lancem de forma explícita ou implícita NullReferenceException, AccessViolationException ou IndexOutOfRangeException. Essas exceções são reservadas e lançadas pelo mecanismo de execução e na maioria dos casos indicam um bug.
Faça a verificação de argumentos para evitar lançar essas exceções. Lançar essas exceções expõe detalhes de implementação do seu método que podem mudar com o tempo.
StackOverflowException
❌ NÃO lance StackOverflowException explicitamente. A exceção deve ser lançada explicitamente apenas pelo CLR.
❌ NÃO capture StackOverflowException.
É quase impossível escrever código gerenciado que permaneça consistente na presença de excedentes de pilha arbitrários. As partes não gerenciadas do CLR permanecem consistentes usando testes para mover excedentes de pilha para locais bem definidos, em vez de recuar de excedentes de pilha arbitrários.
OutOfMemoryException
❌ NÃO lance OutOfMemoryException explicitamente. Essa exceção deve ser lançada apenas pela infraestrutura CLR.
ComException, SEHException e ExecutionEngineException
❌ NÃO lance COMException, ExecutionEngineException e SEHException explicitamente. Essas exceções devem ser lançadas apenas pela infraestrutura CLR.
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.