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

[@vsalbuq]

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

[@maiconjobim6431]

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

[@otaviolemos]

Boa Maicon: obrigado!

[@sidneiferreira5542]

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.

[@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?

[@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!

[@otaviolemos]

Massa né? Agora não consigo fazer de outro jeito mais... 😅

[@Pawl0solidus]

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.

[@otaviolemos]

É isso que eu faço no meu livro.

[@Pawl0solidus]

@@otaviolemos sensacional. Aprendi no curso do Manguinho rsrs

[@otaviolemos]

@@Pawl0solidus veja aqui: kzbin.info/www/bejne/hZ6vaYdneMyhpJo Mas na parte interna da aplicação eu uso o Either. Muito melhor.

[@Pawl0solidus]

@@otaviolemos eu já havia visto seus vídeos sobre o template method e acho esse pattern sensacional. Mas não curto muito a sintaxe desse Either, pra mim deixa o código mais confuso.

[@edward_t450]

seu canal foi um achado, muito obrigado

[@otaviolemos]

Opa, TMJ! 😄

[@matheusmarabesi]

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

[@otaviolemos]

Opa, obrigado Matheus! :D

[@wesleylopex]

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

[@otaviolemos]

Muito obrigado Wesley!

[@georgelobo4048]

Muito bom

[@otaviolemos]

Obrigado!

[@nicolasassisfabrizzi7431]

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!

[@otaviolemos]

Eu entendo seu questionamento e já vi o Uncle Bob criticando checked exceptions. Por outro lado, o que temos aqui está fora do esquema try-catch. Nós retornamos os erros “esperados”, em vez de lançarmos. Eu acho mais elegante assim porque o try-catch é meio goto, quebra o fluxo de controle. Não sei, pelo menos é minha visão atual. Achei legal que no livro Programming TypeScript ele recomenda o uso de coisas parecidas com o Either. Pode ser que eu mude de ideia mas por enquanto estou curtindo essa solução... 😄

[@otaviolemos]

Muito obrigado pelo elogio e pelo comentário!

[@nicolasassisfabrizzi7431]

@@otaviolemos Verdade, não tinha visto por esse lado, o fato de estar fora do try-catch muda bastante o contexto da discussão. Obrigado pela resposta, pretendo implementar em um projeto pessoal e ver como as coisas andam. Ansioso pelos cursos do theWiseDev!

[@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

[@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.

[@otaviolemos]

Boa essa solução né? Ainda não entendi exatamente porque usar o Result genérico o Either; parece-me que dá para usar só o Either (ex.: Either). Estou fazendo uns testes aqui e vou gravar um vídeo mostrando como vai ficar...

[@igorlmfs]

@@otaviolemos eu tmb achei meio estranho, gostei mais das soluções separadas, haha. Os dois juntos me parece mt overengineering.

[@otaviolemos]

@@igorlmfs fiz um refactor aqui na landing page usando só o Either. Vou mostrar em vídeo na semana que vem provavelmente... 😄

[@ErickWendelAcademy]

Ai simmmmm

[@otaviolemos]

Curtiu Erick? Espero que sim! :D

[@gubmx20]

Como o Erick sempre fala nos videos.. o negócio fica bem mais sênior.. rsrs

[@otaviolemos]

@@gubmx20 verdade! 😄

[@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

[@otaviolemos]

Pois é Douglas, é que esse conceito vem da programação funcional. Até onde entendi, o Either é um monad. A questão do Left e Right é que, em inglês, Right também significa “correto”; assim que ficou por convenção o Left como resultados falhos e Right como resultados corretos... Obrigado! 😄

[@soudouglas]

​@@otaviolemos Ah, agora deu para perceber a intenção com a sacada do Right. Obrigado pela explicação!

[@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

[@otaviolemos]

Opa Paulo: provavelmente vou refatorar e usar essa solução na camada de domínio. Quando fizer isso vou documentar em um vídeo também. Quanto aos DTOs, eu acho que isso é utilizado para não ficar passando objetos do domínio para camadas mais externas. São estruturas de dados com as propriedades da entidade, sem os métodos. Eu falo sobre isso no seguinte vídeo: m.kzbin.info/www/bejne/n5abq4ilnamijLs

[@pauloafpjunior]

@@otaviolemos ótimo. Vou ver sim.

[@RenanVital]

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

[@otaviolemos]

É estranho mas me parece a melhor opção, pois reflete o que pode ser a variável. Não sei se você percebeu, mas depois que o usuário é criado corretamente ele cria uma outra variável, desta vez ‘user’ somente, e do tipo User.

[@soudouglas]

@@otaviolemos Bom lembrete essa parte de criar outra variável! Deixá-la com o "orError" no final do nome seria estranho e iria confundir

[@RenanVital]

@@otaviolemos sim, observei essa criação de user. Você acha que dá certo usar desestruturação? Ex.: const { user, error }

[@throyer]

Parece bastante o Optional do java

[@He4dless97]

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

[@otaviolemos]

Eu faria essa validação usando o joi em camadas mais externas. Aí você faz tranquilo. Não vejo tanto problema considerar que o dado chegará validado na camada de entidades.

[@douglasdinizcarvalho7007]

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. PS: tenho fé que um dia essa sugestão será implementada e não precisaremos mais de tantos workarounds: github.com/microsoft/TypeScript/issues/13219

[@otaviolemos]

Acho que você não entendeu direito, Douglas. Se vc quiser usar try/catch, pode usar tranquilamente. A única coisa que não se tem é exceções checadas em tempo de compilação. De qualquer maneira eu apresentei uma solução para NÃO PRECISAR ficar lançando exceção quando a situação não é de fato excepcional. Overengineering comparado com o quê? Você pode substituir engineering com hacks, mas aí terá que pagar o preço também...

[@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. github.com/rocketseat-education/bootcamp-gostack-apps/blob/master/04-iniciando-back-end/src/shared/errors/AppError.ts github.com/rocketseat-education/bootcamp-gostack-apps/blob/e9bcbe055c6a5f7a68d742dc08239958d354cb5b/04-iniciando-back-end/src/shared/infra/http/server.ts#L27