108 - Tratamento Flexível de Erros em TypeScript + Node.js | Princípio da Menor Surpresa 😲

Nesse vídeo eu apresento duas soluções de tratamento de erros em TypeScript que podem ser combinadas.

Note que elas aplicam o Princípio da Menor Surpresa: como a interface do próprio método chamado define os erros que podem ser retornados, o método chamador pode se preparar para o possível recebimento desses erros.

Por outro lado, quando se usa um throw, o chamador pode nem saber que tipos de erros são gerados no chamado e, assim, ser pego de surpresa.

Acho que essas soluções podem te ajudar a pelo menos meditar sobre o assunto e a considerar opções na hora de lidar com erros no TS!

Veja o que acha...

Referências:
Flexible Error Handling w/ the Result Class

Expressive error handling in TypeScript and benefits for domain-driven design

[vsalbuq]

A primeira solução lembra um pouco a estrutura das promises, definindo mais explicitamente o que é uma falha e o que fazer nela

[maiconjobim]

Muito bom o video. No desenvolvimento de mobile com flutter é bastante usado o Either.

[wesleylopex]

Muito bom seus vídeos sobre Clean Architecture com NodeJS, continue fazendo. Ajuda muito

[matheusmarabesi]

Sensacional e de quebra me respondeu a pergunta que fiz no video sobre value objects!!!

Keep it up!!! 🥳🥳🥳

[makakolokao]

Acho bem interessante essa solução, justamente por deixar explícito os erros e não quebrar o fluxo.

Ainda mais com o padrão de poder englobar os parâmetros e resultados de uma interface no seu namespace como Manguinho coloca no curso dele, diminuindo a propagação de mudanças.

Fica fácil definir em Interface.Result os tipos de erros que podem ser retornados. Irei adotar essa solução. Muito obrigado!

[sidneiferreira]

Gostei bastante da sugestão, porém poderia aplicar ele mostrando todas a etapas de forma prática para o exemplo ficar melhor fixado, alguns de nós tem bastante dificuldade ainda de acompanhar eu usou outra abordagem, mas essa eu não consegui ainda utilizar, se não for muito incomodo fazer um mini tutorial explicando as etapas e a forma como o tratamento utilizando o either se comunica, entres os arquivos e as pastas, não consegui aplicar em um projeto NextJS.

[edward_t]

seu canal foi um achado, muito obrigado

[euthomas]

Show, começo logo mais um novo projeto e antes disso vou ler esses artigos. Já estava estudando a possibilidade de mudar pra Java ou c# unicamente pela impossibilidade de usar um throws, já tinha pensado inclusive no instanceof, mas é jogar muita responsabilidade pro programador de lembrar todos os possíveis erros, considerando que o objetivo (pelo menos um dos principais) de usar typescript é justamente ter um help do editor

[nicolasassisfabrizzi]

Achei a solução extremamente elegante, aplica até alguns conceitos legais de FP, e seu conteúdo é simplesmente o melhor que encontrei a respeito de arquitetura e TDD, por favor continue!

Ainda assim uma dúvida está martelando a minha cabeça: não seria essa solução uma implementação apenas mais moderna do que temos no Java como "Checked Exceptions"? Isto é, não estaríamos ferindo um princípio exposto no Clean Code, no capítulo sobre error handling, no qual o uso dessa forma de tratamento de erros é desaprovada pelas várias desvantagens em detrimento das poucas vantagens?

Desde já agradeço a resposta professor, abraço!

[Pawlsolidus]

Ideias interessantes mas achei meio verbosas. Uma ideias tbm bem legais que já vi foi criar um Composite de validações e inicializar com um array de possíveis validações, assim fica mais encapsulado e usamos classes pequenas para realizar essas validações. Assim de dentro dessas classes podemos retornar os erros ou lançar as exceções.

Podemos então criar um decorator de tratamento de exceção que envolve um controller, então o controller não teria nenhum try catch, nem mesmo os use cases, este estaria dentro do decorator que receberia como parâmetro um controller e executaria seu método handle dentro do handle do decorator envolvendo ele em um try catch. Assim teremos um único ponto no código com tratamento de exceção.

[impervictor]

Tenho uma pasta "Presentasion/Mails" com vários templates de emails e cada um deles recebem "dados" diferente, como faço para tipar esses templates com os dados que cada um deve receber, e lançar um erro caso venha faltando?

[igorlmfs]

Professor, gostei da solução, vou adotar. Havíamos conversado sobre isso na aula de VVS, achei bem elegante mesmo. Sempre foi um dos meus maiores dilemas: Como tratar um erro que não é uma exceção, hahaha. Eu ainda gosto da solução que eu bolei usando um único try catch em uma BaseController em um método chamado ProcessRequest. Nesse método eu basicamente recebo uma função de callback, que passo nas controllers específicas, e retorno a execução dessa função, esse bloco de código fica dentro do único try catch do código que tem todos os tipos de exceções que eu criei para cada tipo de erro, como por exemplo: "KeyNotFoundException", "ArgumentInvalidException", daí dentro de cada catch específico eu escolho o código http adequado e retorno um objeto ErrorResponse com a exceção e a mensagem de erro. No entanto, parando para pensar pelo lado da perda do fluxo de controle é algo realmente estranho, uma vez que eu vou sair da camada de domínio e saltar na memória para uma BaseController lá da camada de apresentação. O único trade off que vejo no uso do Result com Either é o fato de que vou ter um bloco switch case para tratar os erros de cada objeto do meu domínio. Foi algo que eu tentei evitar quando pensei no uso de exceções como "ArgumentInvalidException", mas, nesse caso eu acabo perdendo um pouco de semântica no código usando exceções mais genéricas. Se for um Rest, para quem está consumindo o impacto é zero, mas para quem for ler o código pode ficar confuso, haha.

[soudouglas]

Bem legal, o tratamento com o combine ficou bastante limpo!

Só não achei muito bom as classes se chamarem Left e Right porque a gente estaria explicando como o Either funciona e quem visse isso pela primeira vez não entenderia a lógica. Mas vou testar isso com certeza

[pauloafpjunior]

Bem legal mesmo. Já tinha visto essa solução com o Result. Já com o Either, ainda não.

Uma dúvida: por que você preferiu não usar o Result nas _entities_ também?

Outra questão: você está usando tipos diferentes para entidades que serão persistidas no banco? Vejo o pessoal usando DTOs para isso. Você já viu algo a respeito?

Obrigado pelo vídeo

[RenanVital]

Bacana a solução proposta, só achei um pouco estranho a sintaxe das variáveis com ...OrError

[douglasdinizcarvalho]

Fala Otavio! Gostei bastante da explicação e do vídeo em geral. Em relação aos padrões apresentados, mesmo entendendo a utilidade deles, ainda vejo como overengineering. Espero que um dia o TS não peque tanto em relação ao princípio da menor surpresa e nos possibilidade tratar as exceções de forma simples.

[Hedless]

Otávio, tenho uma dúvida sobre inclusão de libs externas na camada de entidade.
Eu poderia validar manualmente, mas gosto da ferramenta Joi para validação e queria usar para validar uma entidade. Acho bem mais produtivo. Queria saber se é grande de mais o pecado de algo do domínio depender de uma lib de terceiros

[caquintella]

Ainda continuo achando que tratamento de erro está feio em TS.

[Megatorial]

Já vi a galera fazer um AppError e usar a lib error-express evitando toda complexidade, mas n sei se isso é problema, para mim parece elegante e simples.