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

• Código Limpo: 2. Funções

• 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, 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.