Error Handling in Express
Vložit
- čas přidán 9. 07. 2024
- 🔥More exclusive content: productioncoder.com/you-decid...
Twitter: / _jgoebel
Blog: productioncoder.com
Code: github.com/productioncoder/ex...
In this video, we cover how do error handling in express and Node.js. We explain how to return expected errors and how to not leak internal details of your application in case of unexpected errors.
00:00 application walk through
01:30 a better way of hard coding HTTP status codes
02:36 defining API errors with status codes
04:19 creating an API error handling middleware
07:14 making use of next in express
08:14 plugging our our api error handling middleware into our router
08:55 making use of our predefined API errors
10:17 testing our error handling
11:03 preventing leaks from unexpected errors
The way you implemented it feels like the way it was intended to be, I found this really helpful
Thanks, I'm glad you liked it 👍
Great explanation ! Sort, easy and with big impact!
thx
Probably the best vid on express error handling, thanks!
thx, I'm glad it helped!
I was looking for this approach from a long time. Thanks a lot
you're welcome Pratik 👍
Loved the video! I would like to see one like this doing Content Negotiation and using the route information to know whether or not to throw a 406 or 415 if you have a variety of routes (GET & POST) and you have to know based on the route whether this route would ever be returning a payload, if not, then no need to throw a 406 error. Similarly for the 415.
Perfect, simple and efficient. Thanks man
thx Pablo
This video blow my mind to a new perspective, thank you
thx Ivan
As clean as it could be. Thanks for sharing.
Thanks 👍
i luv u 💖💖 , u might not know how much you helped me.
Awesome explanation, it was really helpful👏🏽 subscribed!!
Awesome, thanks Nico 👍
Well done! Thanks for this.
Glad you enjoyed it!
Thank you very much mate, helped me a lot !
Glad to hear that!
thank you, I was looking for this solution for days.!!!!
You are most welcome
Thank you so much, that was very helpful!
Glad it was helpful!
Really clean explanation, I'm going to use this in University Project. Have a good day.
thanks, I hope it helps 👍
Good tutorial. Keep up the good work!
thx Anutei
Got a lot of insight from this video
I'm glad it helped
what a great channel man 👍💪, I saw some of your videos and you are a really good teacher man, so happy I stumbled upon your channel .. one question I have is what do you mean by data leakage .. what kind of data do you mean, like where the code errored out maybe or what?
e.g. let's assume you have some manhandled error, you might by accident return the call stack to the client. This might be problematic in terms of security.
Would you consider throwing an error instead of returning it in the class constructor?
Outstanding explanation sir 🏆
thx 👍
Thank you a lot!!!
you're welcome!
Thank youuuu!!
you're welcome 👍
Thanks for useful info
Glad it was helpful!
In case someone is wondering, how does express know it's an error handler middleware ? The number of arguments is 4!!! (err, req, res, next)
exactly Euquila. Thx for the nice addition 👍
Great way to use class for error handling.
thanks
What is the purpose of "static internal" method if you nerver used it?
I personally would leverage try catch block and extend ApiError to the native Error object
I like your stuff. I saw that you're German as well so Hallo von mir 👋
Thx, schöne Grüße nach Erfurt 😁
Great tutorial, very logical. Just wondering how to send error message to the front end, do we need another res.send to send error message ?
Hi Luke, we return the error message in the error handling middleware that we plug in at the very end
5:38 Thanks for point it out, I alway wonder why I can't console in nodejs
👍
The generic error gona work for every kind of error? Like bugs, connection problems with db, etc ?
yes, any error that is not anticipated, i.e. that is not an instance of ApiError will be caught
nice
thanks
thx Konrad, you're welcome!
why you return; empty just to stop the program instead of returning next(new ApiError(404,blabla)), is there any difference?
because then it would look like you have to return the value of the next(new ApiError(...)) which you don't because the call to next just passes on the control to the next available middleware.
@@jgoebel so the middleware will stop passing to next() till that point?
Is it acceptable to use ApiError inside services? Or is it intended to be used only in controllers?
I would primarily use it in controllers because the service layer should only handle business logic
@@jgoebel I'm a bit struggling with handling business logic errors. Imagine there is a login service, which can throw errors because 1) Username can't be found, 2) Password is incorrect. The appropriate status codes would be 404 and 400, respectively. However, since the business logic shouldn't be aware of http stuff, how the controller knows which status to send to the client?
@@turan_sultan you could throw custom errors and then depending on what error you get, you return the proper status code. The error handling shown in this video is the simplest form of error handling available.
Technically speaking you could make it more sophisticated, make custom errors and then check in your error handling middleware which error it is. Now if somewhere in your service an error is thrown, you would eventually end up in the error handling middleware which would automatically return the correct status code. In this case the controller would not be involved. This approach is probably the most flexible one
@@jgoebel Thank you, the second method is what I will probably implement. I don't know if it is just me, but it is rare to find a proper way of doing a thing in express, especially when it comes to architecture. Many times I find myself reading articles/stackoverflow on Nest.js or Java Spring.
It's clear and simple but, when you work with async functions it all gets messy
subscribed
thx
bro i have .unshift error in my code plse help me out of it in express
Hi Sumit, I don't think this is related to the error handling code in the video because there we do not use unshift
Sorry but i was doing a blog website project by git hub of clever programmer so i got an error ao i thought here i have chance to get help😅 so that's the reason i wrote my issue.
Plse help me on that problem
@@sumitpandey6958 Looks like your array at which you call unshift is null or the indexes which you are passing are already out of bounds
In api-error--handler.js, you are checking if err is instance of ApiError. What if we have a large number of Error classes, do we check if error is instance of a specific error class? And why do we check this? I don't see any point of this, we are just setting the status code and sending the error message as json. Shouldn't this be common for all types of errors? Or we can just inherit all errors from a common class and check only if error is instance of that base class?
we do this to not by accident expose any internals to the client (in case there is an error we do not anticipate). Yes, you could also create your custom error types and inherit from Error directly
@@jgoebel got it. Thanks
{2023-09-01}
zoom a bit more next time😅
sure, will do next time
the github repo doesn't exist
thanks for the hint. Sry. I forgot to make it public. Now it should work: github.com/productioncoder/express-error-handling