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: 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.
Top comments (0)