Usando tipos de exceção padrão
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.
Esta seção descreve as exceções padrão fornecidas pela estrutura e os detalhes de seu uso. A lista não é, de modo algum, exaustiva. 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 deite System.Exception fora ou System.SystemException.
❌ NÃO pegue System.Exception ou System.SystemException no código de 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 deite fora nem derive de ApplicationException.
InvalidOperationException
✔️ NÃO lance um InvalidOperationException se o objeto estiver em um estado inadequado.
ArgumentException, ArgumentNullException e ArgumentOutOfRangeException
✔️ DO throw 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.
✔️ DO define a ParamName propriedade ao lançar uma das subclasses de ArgumentException.
Esta propriedade representa o nome do parâmetro que causou a exceção a ser lançada. Observe que a propriedade pode ser definida usando uma das sobrecargas do construtor.
✔️ DO use value para o nome do parâmetro de valor implícito de setters de propriedade.
NullReferenceException, IndexOutOfRangeException e AccessViolationException
❌ NÃO permita que APIs publicamente chamáveis lancem NullReferenceExceptionexplícita ou implicitamente , 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 ao longo do tempo.
StackOverflowException
❌ NÃO lance StackOverflowExceptionexplicitamente . A exceção deve ser explicitamente lançada apenas pelo CLR.
❌ NÃO APANHE StackOverflowException.
É quase impossível escrever código gerenciado que permaneça consistente na presença de estouros arbitrários de pilha. As partes não gerenciadas do CLR permanecem consistentes usando testes para mover estouros de pilha para locais bem definidos, em vez de recuar de estouros de pilha arbitrários.
OutOfMemoryException
❌ NÃO lance OutOfMemoryExceptionexplicitamente . Essa exceção deve ser lançada somente pela infraestrutura CLR.
ComException, SEHException e ExecutionEngineException
❌ NÃO lance COMExceptionexplicitamente , ExecutionEngineException, e SEHException. Essas exceções devem ser lançadas apenas pela infraestrutura CLR.
© 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.