Tratamento de erros no Express.js com TypeScript

[@LeandroCorso]

Sou de front e precisava fazer uma API em node e o seu conteúdo tá me ajudando pra caramba! Valeu. Uma coisa que pode ser legal pra deixar os erros ainda mais flexíveis: quando vc cria as classes dos erros vc passa o status code pra não precisar preencher, mas dá pra fazer com a mensagem tbm: export class UnauthorizedError extends ApiError { constructor(message: string) { const msg = message ?? "Unauthorized"; super(msg, 401); } } Daí na hora de lançar o erro vc pode simplesmente fazer assim: throw new UnauthorizedError(); Mas se preferir pode lançar a mensagem personalizada: throw new UnauthorizedError('You're not authorized to stay here! Get out!');

[@gabrielrodriguesricardo]

Top demais utilizar esse recurso de herança de classes (POO). O código fica muito mais simples e fácil de manutenção. No .NET isso já vem default. Parabéns, Guido! Ganhou um seguidor :)

[@moacirdavid3562]

Muito boa sua didática, Guido! Bem objetivo e claro! Parabéns!!

[@nellfs]

Cara, valeu demais, eu tava perdido aqui com um erro no throw em async e pensava que era meu código, passei o dia pesquisando oque tava rolando, no final da noite cai aqui, logo no minuto que você fala sobre o problema do express com async/await do ES6 e sua recomendação da lib express-async-erros, você é meu herói!

[@guidocerqueira]

Hahaha que massa. Fico feliz em saber que te ajudou de alguma forma. Sucesso!

[@robertocaliz4143]

Muito obrigado pelo conteúdo! Certamente vou aplicar em meus projetos.

[@toskito123]

Cara, que daora, era isso mesmo que eu tava procurando aprender, muito obrigado

[@lucca4345]

vídeo impecável!! muito didático e esclarecedor, obrigado pelo conteúdo :D

[@brunofelixf]

Que ótima solução e excelente didática... obrigado por compartilhar! 👏👏👏

[@edsonbreno5763]

Obrigado pela aula, @Guido! 😃

[@gatogordo4131]

Estava acompanhando uma vídeo aula aonde esse tema foi abordado de maneira superficial. Seu conteúdo me ajudou a aprofundar e a melhorar meu código :D

[@JoaoVitor-pc4ps]

Cara, tava precisando dessa dica, já tava cansado do try catch hahaha, valeuuu! 🤘

[@viniciuspereira5278]

Teus vídeos são incriveis cara! Parabens!!

[@guidocerqueira]

Muito obrigado pelo feedback, Vinicius!

[@jpcc1223]

Muito bom o conteúdo! Com certeza vou implementar em meus projetos! Obrigado pelas dicas

[@matheussudre4354]

Parabéns pelo conteudo, cai aqui por acaso, mas amei demais essa forma de tratar os erros

[@maiconpereiradesouza5533]

Muito bom!!!! Obrigado pelo conteúdo!

[@GilsonAlvessout]

Guido já estou utilizando no segundo desafio da cubos/ifood vlw ótimo conteúdo

[@pietrosouza4443]

Muito bom, ajudou bastante, obrigado! 🙂

[@LucasOliveira-bg3bj]

Muito obrigado pelo conteúdo! Se pudesse dava dois likes!

[@edsonmartinelli]

Bom vídeo, amigo. Para aqueles que tiveram algum problema por usarem funções assíncronas, recomendo que utilizem o argumento next da própria função de rota para passar o erro ao invés do throw. Esse problema será resolvido com a chegada do Express 5, mas ele ainda se encontra em beta.

[@James-kq5wb]

cara, sensacional, excelente video

[@guidocerqueira]

Muito obrigado pelo feedback, James!

[@DieDona]

ótimo vídeo, muito obrigado!

[@juaciu-_-6484]

Qual a diferença de criar uma unica instancia de um controller e fazer como você fez, uma instancia para cada rota? Tem alguma diferença?

[@igorribeiro632]

Video top demais, porém continuei precisando utilizar o try catch para passar meu erro para o middleware, pq ele estava ainda sim travando minha aplicação

[@laurentino547]

👏🏼👏🏼👏🏼👏🏼

[@quicksketch1617]

Olá, muito ótima explicação. Uma dúvida, como você sabe que existe um tipo Request.Response e NextFunction, pra usar o typescript?

[@gabrielkyomen4782]

Salve Guido, ótimo vídeo como sempre! Essa abordagem é realmente boa para tratar aqueles erros inesperados sem ter um trycatch em cada função, porém queria tirar algumas dúvidas: Primeiro na tipagem do erro do middleware, 'Error & Partial', por ApiError ter um 'extends Error', não daria para simplificar, deixando apenas 'Partial'? Outra coisa é que já ouvi falar que o uso de throw para lidar com problemas pode ser custoso para a performance da aplicação. Isso é verdade? Se for, não seria melhor usar a abordagem apenas para os erros inesperados? Talvez apenas criando um helper para retornar erros comuns, sem lançar eles? Valeu demais pelo vídeo! Bom ano novo

[@brunodepaula5293]

Da pra fazer isso usando o pattern de decorator seja com express ou nao.

[@ldstudio3044]

tom muinto obrigado

[@dhiegopereira]

Very good

[@felipematheus6518]

top demais!

[@wagnerfillio1031]

E se lançar um erro do zod ou prisma que são específicos?

[@lucasmedeiros9755]

Cara, uma pergunta: Nesse file de routes, pq cada rota tem uma nova instancia do controller? Não seria melhor receber no constructor como no dot net ou spring sem autowired?

[@paulosoares8626]

Show

[@er1v4n-hu3]

Uma dica: Se o controller usar funções assíncronas, ainda vai precisar de um try-catch pra pegar o erro (o express não pega erros assíncronos), mas pode ser feito só chanando a "next(err)" dentro do catch e vai pro middleware.

[@aspli]

Mas o import 'express-async-errors' não resolveu o problemas das funções assincronas? Ainda assim vou precisar do try-cath?

[@larissacavalcante7253]

@@aspli estou com o mesmo problema, ele n funciona sem o try and catch, mesmo com o import

[@neederp]

valeu cara, tava quebrando a cabeça aqui

[@williamfreitas]

no meu aparece isso UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "#".

[@jhonnyfreire]

Será que alguém aqui conhece uma alternativa ao express-async-errors? A última versão publicada tem 5 anos.

[@HypeMansion]

mas funcona perfeitamente, nao mudou nada pq é simples

[@luigginosa809]

perfeito

[@Ronielcs]

Olá @guidocerqueira , primeiramente sensacional o seu vídeo, gostaria de uma ajuda sua, fiz o teste aqui utilizando as novas versões do Node e do Express e a biblioteca express-async-errors parece não funcionar mais para as async functions, conseguiria fazer um exemplo com as novas versões? Ajudaria muito aqui rsrsrs abraços.

[@HypeMansion]

estou no express 4.18.2 e funcionando, eu tive que revisar umas promises que eu tinha escrito errado sem tratamento no reject

[@ogustavovasquez]

Vídeo muito bom. Obrigado! Mas fiquei me perguntando por que não retornar para o client o statusCode e o nome do erro no objeto também? Seria errado?

[@guidocerqueira]

O status code já é retornado no status da resposta. Vc pode retornar um objeto com todas essas informações também, mas não faz muito sentido, pelo menos em produção. Uma opção é você retornar um objeto com as informações do erro apenas em ambiente de desenvolvimento.

[@LeandroCorso]

Resolvi implementar o YUP pra fazer as validações da minha API. Por padrão o método validate() usa uma promise pra retornar os erros encontrados. Nesse caso ele usa o then/catch e não tem muito como fugir disso, correto? Uma vez que usando o método isValid() retorna booleando sem o objeto com os erros de validação. O que fiz foi colocar no catch do validate() o throw new BadRequestError(err.message). Existe uma outra forma mais interessante de fazer essa validação ou vc recomenda manter do jeito que está? export class AreasController { index = async (req: Request, res: Response) => { getAllRecordsSchema .validate(req.query) .then(async () => { const data = await getAllRecords(req.query, entity); res.json(data); }) .catch((err) => { throw new BadRequestError(err.message) }); };

[@guidocerqueira]

Se você tiver implementado o tratamento de erros, ao lançar uma exceção pelo validate já será captado pelo middleware de tratamento de erros

[@leonardohirosue9376]

Ótima aula e ótima didática! Cheguei até o video pois estou enfrentando um problema em minha aplicação, e infelizmente o meu "express-async-errors" não funcionou de jeito nenhum 😢 Algum palpite do que pode ser? E antes que eu me esqueá, parabéns pela organização, vou aderir a tratativa dos erros em meus códigos 👍

[@guidocerqueira]

Obrigado pelo feedback, Leonardo. Sobre o problema, gera algum erro?

[@leonardohirosue9376]

@@guidocerqueira A aplicação continua quebrando ao invés de retornar a mensagem e o statusCode. Acredito que seja algo no meu Setup...

[@guidocerqueira]

Se quiser, depois me manda uma mensagem no Instagram q tento te ajudar

[@vonbruhh]

Tava com esse problema e consegui resolver. No meu caso, eu to chamando um service dentro de um controller, mas só o service tava como async/await, porque é quem acessa o banco de dados. Deixei o controller como async/await e resolveu o problema.

[@gilvanbatista8402]

Eita Guido cerqueira from cubos!! KKKKKKKKKKK pfv me diz que esse canal tem um curso de typescript completo não vou conseguir aprender backend com outra pessoa

[@viniciusduartepasso6639]

Isso funciona no nest.js?

[@darksideeditions4251]

Deve existir modo de fazer algo para ele, mas esse caso em especifico é em express.

[@pedrofaria7322]

Quando eu tenho um erro assíncrono, como por exemplo o jwt.verify() que retorna um erro caso a assinatura do jwt não seja válida, eu só consigo retornar o erro com status 500 e "internal server error", em vez de conseguir personalizar esse erro. Tem como fazer isso sem usar o bloco try catch?

[@guidocerqueira]

Você pode verificar o erro no middleware de erro e pegar o tipo de erro do jwt, assim vc consegue personalizar. Pra isso, vc precisa ver qual erro estoura quando se trata do jwt.verify()

[@pedrofaria7322]

@@guidocerqueira Apesar disso, gostei muito desse padrão de tratamento de erros, achei bastante organizado. Ví seu tutorial de criação de uma API rest e aprendi demais, por favor continue com os seus vídeos, você ensina muito bem

[@TheJhonny9943]

Olá amigo assisti o seu video a um tempo atras e me foi muito útil ... mas do nada parou de funcionar. os dados não caem mais no middleware de erro. Eu estou em uma pilha de nervos com isso já , olhe seu video e refiz tudo do zero , e o mesmo erro persiste. Além disso ele ainda trava meu backend , fazendo com que eu tenha que reiniciar o servidor manualmente. já pegou algo parecido , se sim pode me dar uma luz ?

[@guidocerqueira]

Fala Jhonnatan. Teria como vc compartilhar o erro que você está recebendo? Fique tranquilo que vou te ajudar

[@euassistovc3325]

Por algum motivo o nome do meu erro não altera, o nome fica padrão (Error) e ao lado dele o nome customizado, exemplo: Error [ApiError], e então eu mudei manualmente com this.name e dei um nome diferente do nome da classe, exemplo ApiErrorDois, e o nome alterou normalmente após isso. Por disso? Não pode usar o mesmo nome da classe?

[@guidocerqueira]

Tenta passar o seguinte: this.name = this.constructor.name assim ele vai pegar o nome da classe

[@euassistovc3325]

@@guidocerqueira também nao foi, muito estranho porque isso só acontece se o nome do erro for exatamente igual ao nome da classe, se passar, nesse exemplo, um ApiErrorr (com um r a mais) , ele funciona normal, também já testei e é igual com as outras classes de erro

[@guidocerqueira]

Realmente é estranho. Me manda um print do seu código em alguma das minhas redes sociais que tento te ajudar. Vamos resolver isso