Boas práticas de tratamento de exceção com exemplos em c#

escrito por Sandré Pereira

Published in

stonetech

4 min readJul 4, 2022

Quando pensamos em um problema, e esse problema é um erro de código, pensamos em exceção. Antes de falarmos sobre exceção é importante definir que tipo de erro é traduzido por uma exceção. Existe ao menos três formas de gerar um erro de código, são elas;

Erro sintático, quando já na compilação encontramos um problema, o qual é motivador para não ocorrer uma compilação.
Erro em tempo de execução, são aqueles que conseguimos compilar e durante algum tratamento lógico, de regra, encontramos uma exceção. E para nós durantes os próximos minutos será o tipo de erro tratado.
Erro lógico, esse é encontrado sempre que nossa regra, escopo, lógica de negócio, ou quaisquer outra definição, tem consigo uma falha de lógica, pleonasmo? Vou exemplificar: Um método chamado Soma, onde na verdade seu comportamento é uma subtração. Temos aqui um erro lógico que possivelmente não terá erro sintático ou em tempo de execução.

Todos os tipos de erro que definimos podem ser tratados, pensando nisso vamos então elencar boas práticas para o tratamento de exceções, os erros que podem ocorrer em tempo de execução. Na ordem:

Mensagens gramaticalmente corretas
Usar exceções predefinidas do .NET
Usar exceções “tipadas”
Não jogue uma exceção em nada!
Use throw no lugar de throw ex

1. Mensagens gramaticalmente corretas

Uma mensagem de erro é um texto como qualquer outro, e para isso é importante escrever de forma que a gramática minimamente seja correta. Não digo que deva escrever um novo capítulo de um livro, gramaticalmente perfeito, mas que a mensagem de erro leve consigo a informação que deve passar.

2. Usar exceções predefinidas do .NET

Criar um novo tipo de exceção deve ser feito sempre que alguma predefinida não for aplicável ao seu erro. Geralmente isso ocorre quando temos possíveis erros de regra de negócio, mas podemos falar sobre isso no tópico 3. Alguns exemplos de exceções predefinidas são;

NotImplementedException: Quando algum escopo ainda não tem uma implementação definida ou concreta.
ArgumentNullException: Quando uma referência nula é passada a um método que não aceita null como argumento válido.
UnauthorizedAccessException: Quando é negado acesso a um input/output (escrever em um arquivo somente leitura, por exemplo), ou um erro de segurança.

Claro que esses são exemplos de exceções mais utilizadas e vale desbravar mais sobre as exceções definidas e sempre fazer a seguinte pergunta: Devo mesmo criar um novo tipo, ou usar a simples Exception, ou existe alguma classe que melhor define o meu erro?

3. Usar exceções “tipadas”

Quando as exceções predefinidas não forem adequadas, seja por quaisquer motivos, até mesmo o semântico ou de adequação ao seu modelo de arquitetura, crie exceções tipadas. E para isso, duas dicas;

Termine sua nomenclatura com Exception, por exemplo; UserNotFoundException.

Crie construtores para sua classe de exceção tipada, dando flexibilidade para escrever uma mensagem de erro ou resgatar uma exceção mais interna, por exemplo.

4. Não jogue uma exceção em nada!

Espero que durante sua experiência como desenvolvedor(a) não tenha encontrado uma exceção sendo jogada em nada. Existe um problema imenso em fazê-lo já que existe uma intenção de registrar um problema, mas que não é feito e não haverá vestígios da ocorrência. Se existir incerteza no que fazer com sua exceção vale uma reflexão em talvez lançar novamente, não ter a intenção de pegá-la ou revisar o bloco causador de erro.

Isso é muito ruim.

5. Use throw no lugar de throw ex

Quando uma nova exceção é lançada o intuito é que suas informações sejam preservadas para utilização, quando usamos throw no lugar de throw ex preservamos as informações do real erro. Dessa forma, veja o resultado dos dois cenários de uso:

Throw

throw (erro 1) → throw (erro 2) → N → erro 1 + erro 2 + N

Aqui temos nossa pilha de erros intacta, elencando todas as informações da camada mais interna para a mais externa. Entenda N como muitos outros throw.

Throw ex

throw (erro 1) → throw ex (erro 2) → erro 2

Aqui temos nossa pilha com o viés de que somente a última pilha define nosso erro, elencando somente a camada mais externa.

Considerações

Aqui vimos os principais tópicos sobre boas práticas de tratamento de exceções, claro que abre precedente para falarmos sobre mais práticas e mais técnicas de tratamento, porém, considero que aqui já conseguimos enriquecer a forma como lidamos com quebras de pilha.