Clean Code: Exceptions e Tratamentos de Erros
Tags: cleancode, exceptions, codegirl, codewomen
Published: 2020-04-02 23:31:06

Esse artigo é um de uma série que fala sobre vários tópicos relacionados a Código limpo, seguem os tópicos relacionados abaixo:

* [Código Limpo: 1. Introdução](https://dev.to/marylly/clean-code-introducao-bfb)

* [Código Limpo: 2. Funções](https://dev.to/marylly/clean-code-funcoes-3n78)

* Código Limpo: 3. _Exceptions_ e Tratamento de Erros [Você está aqui!]

No nosso dia-a-dia, nós temos que lidar com erros, problemas e direções que algumas situações tomam na nossa vida, algumas podemos reverter, diminuir os impactos ou simplesmente aceitar o fato em sí, decisões e fluxos de fatos podem caminhar para erros e problemas. Contextualizando, imagine que você tenha um celular e você contrata um seguro, para reduzir os impactos negativos financeiros, perda de bem ou só o fato de ficar sem o aparelho celular, você não deseja que esses problemas aconteçam, mas caso sim, o seguro existe para minimizar esses impactos negativos.

Assim como na vida real na situação contada acima, estamos passíveis de erros e problemas nos softwares que construímos e utilizamos, e é uma ferramenta que pode reverter ou minimizar os impactos negativos desses erros são as _Exceptions_ ou Exceções.

O conceito de _Exceptions_ nasceu na linguagem LISP e é uma ferramenta que permite identificar de forma amigável e tratar erros que estão fora do fluxo normal e esperado do software.

Como pessoas desenvolvedoras, é nosso dever reduzir os impactos negativos dos erros de software na vida das pessoas que utilizam o mesmo, e assim como na vida, podemos escolher lidar com (ou ignorar) o ocorrido.

Muitas linguagens possuem suporte a _Exceptions_, mas existem algumas linguagens que não possuem, C, Perl, Pascal, Golang são exemplos que não possuem suporte.

### Principais fontes de _Exceptions_
* Falhas de hardware;
* Falhas de dispositivos;
* Falhas de rede e comunicação;
* Erros de programação;
* Erros de sintaxe;
* Entrada dados com tipo incorreto.

### Tratando erros
Algumas das estruturas (statement) disponibilizadas por linguagens de programação é a _try-catch-finally_ ou a utilização de _error handler_ ou _wrappers_. Essas estruturas permitem que para determinado fluxo de execução, seja possível recuperar-se sabendo qual erro, a identificação 
 e alguma informação específica do fluxo para resolver ou contornar o problema.

### Exceções verificadas
O conceito de exceções verificadas foi criada e disponibilizada na linguagem Java por [Jim Waldo](https://en.wikipedia.org/wiki/Jim_Waldo), e consiste em incluir na assinatura de todo método a lista de todas as suas exceções que pode passar para a sua chamada. Saber quais possíveis _Exceptions_ pode ser muito benéfico para leitura e entendimento do que acontece num método, mas toda vez que uma nova _Exception_ é adicionada num método ou função, é necessário:
* modificar a assinatura do método/função;
* modificar as chamadas adicionando um Throw para nova _Exception_.

E podem:
* gerar uma alteração em cascata de várias chamadas do método/função;
* acrescentar complexidade do código;
* quebrar o encapsulamento da implementação, porque no tratamento do _throw_ é preciso dar detalhes da implementação da _Exception_ para fazer a tratativa do erro;
* violar o Princípio Aberto-Fechado (_Open-Closed Principle_) do SOLID de classes estarem abertas para extensão, mas fechadas para alteração.

### Exceções _não_ verificadas
Esse tipo de exceção não precisa ser explicitada para o seu chamador (método ou função). Possuem as vantagens em relação as Exceções verificadas:
* não quebra o encapsulamento, menor dependência da implementação das _Exceptions_;
* não viola o Princípio Aberto-Fechado (_Open-Closed Principle_) do SOLID;
* menos código, menos bug;
* código limpo sem todas as tratativas de todas as _Exceptions_ possíveis.

Porém existe a desvantagem que deixa a implementação do código misteriosa, não tendo muitos detalhes das _Exceptions_ possíveis, talvez exista no código apenas as _Exceptions_ mais críticas tratadas.

### Boas práticas

* se a _Exception_ pode ser descartada por uma correção no código, FAÇA A CORREÇÃO;
* tenha uma classe abstrata que padronize a estrutura e os atributos de todas as informações necessárias quando uma _Exception_ for levantada;
* crie tratativas para _Exceptions_ especifícas, prefira as classes de _Exceptions_ concretas;
* forneça contexto mínimo na sua _Exception_ para identificar a origem e a localização do erro (onde isso aconteceu mesmo no código?);
* contextualize suas _Exceptions_, por exemplo, tenha a classe concreta _LoginException_ herdando a classe abstrata _Exception_ padrão e onde centraliza todos os erros tratados do contexto da funcionalidade de login;
* no retorno de uma função ou método que seja _Null_, substitua por uma _Exception_, evitando verificações desnecessárias se um retorno é = a _Null_ sem muita informações do por que tem este retorno;
* forneça a _Stack Trace_ somente se necessário, caso contrário disponibilize o mínimo possível de informação (Isso pode virar uma falha de segurança);
* tenha em mente que essas informações podem ser exibidas num erro na tela do seu cliente que pode ficar confuso ou até diminuir a confiança do mesmo;
* tenha em mente que essas informações podem ser exibidas para alguém mal-intencionado que pode usar para identificar falhas que podem ser exploradas no seu código;
* tenha em mente que isso pode ser uma informação muito útil coletada no monitoramento do seu ambiente: utilizada, consolidada e mensurada para feedback rápido de problemas no seu software durante a utilização do mesmo;
* por favor 🙏, testem suas *Exceptions*.

### Conclusão e reflexão

Tenha em mente que a utilização de _Exceptions_ não previne erros. A ferramenta ajudará a errar melhor ou menos para que os problemas sejam mais rapidamente identificados e corrigidos, além de trazer uma qualidade na construção do seu código.

Boas _Exceptions_ e até mais! =]

### Referências

[1] Martin, Robert. **Código Limpo: Habilidades Práticas de Agile Software.** Altabooks, 2011. Rio de Janeiro.
[2] Wikipedia. **Tratamento de Exceções.** Disponível em https://pt.wikipedia.org/wiki/Tratamento_de_exce%C3%A7%C3%A3o, acessado em 02 de Abril de 2020 às 17:48.
[3] Wikipedia. **Exception Handling.** Disponível em https://en.wikipedia.org/wiki/Exception_handling, acessado em 02 de Abril de 2020, às 19:32.
[4] Coding Horror. **The First Rule of Programming: It's your fault.** Disponível em https://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/, acessado em 02 de Abril de 2020 às 20:10.
[5] Coding Horror. **Retrowing Exceptions.** Disponível em https://blog.codinghorror.com/rethrowing-exceptions/, acessado em 02 de Abril de 2020 às 20:19.
[6] Coding Horror. **What's Worse Than a Bad Error?** Disponível em https://blog.codinghorror.com/whats-worse-than-a-bad-error-message/, acessado em 02 de Abril de 2020 às 20:24.
[7] Coding Horror. **Creating Even More Exceptional Exceptions.** Disponível em https://blog.codinghorror.com/creating-even-more-exceptional-exceptions/, acessado em 02 de Abril de 2020 às 20:29.