The way you implemented it feels like the way it was intended to be, I found this really helpful

@jgoebel

3 жыл бұрын

Thanks, I'm glad you liked it 👍

Great explanation ! Sort, easy and with big impact!

@jgoebel

3 жыл бұрын

thx

Probably the best vid on express error handling, thanks!

@jgoebel

3 жыл бұрын

thx, I'm glad it helped!

I was looking for this approach from a long time. Thanks a lot

@jgoebel

3 жыл бұрын

you're welcome Pratik 👍

Perfect, simple and efficient. Thanks man

@jgoebel

2 жыл бұрын

thx Pablo

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.

Awesome explanation, it was really helpful👏🏽 subscribed!!

@jgoebel

2 жыл бұрын

Awesome, thanks Nico 👍

As clean as it could be. Thanks for sharing.

@jgoebel

3 жыл бұрын

Thanks 👍

This video blow my mind to a new perspective, thank you

@jgoebel

2 жыл бұрын

thx Ivan

Really clean explanation, I'm going to use this in University Project. Have a good day.

@jgoebel

3 жыл бұрын

thanks, I hope it helps 👍

i luv u 💖💖 , u might not know how much you helped me.

Well done! Thanks for this.

@jgoebel

Жыл бұрын

Glad you enjoyed it!

Thank you so much, that was very helpful!

@jgoebel

2 жыл бұрын

Glad it was helpful!

Thank you very much mate, helped me a lot !

@jgoebel

Жыл бұрын

Glad to hear that!

Good tutorial. Keep up the good work!

@jgoebel

2 жыл бұрын

thx Anutei

thank you, I was looking for this solution for days.!!!!

@jgoebel

2 жыл бұрын

You are most welcome

Would you consider throwing an error instead of returning it in the class constructor?

Outstanding explanation sir 🏆

@jgoebel

2 жыл бұрын

thx 👍

Got a lot of insight from this video

@jgoebel

Жыл бұрын

I'm glad it helped

Thanks for useful info

@jgoebel

2 жыл бұрын

Glad it was helpful!

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?

@jgoebel

2 жыл бұрын

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.

Thank you a lot!!!

@jgoebel

3 жыл бұрын

you're welcome!

Great way to use class for error handling.

@jgoebel

3 жыл бұрын

thanks

Thank youuuu!!

@jgoebel

3 жыл бұрын

you're welcome 👍

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 ?

@jgoebel

2 жыл бұрын

Hi Luke, we return the error message in the error handling middleware that we plug in at the very end

I personally would leverage try catch block and extend ApiError to the native Error object

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)

@jgoebel

3 жыл бұрын

exactly Euquila. Thx for the nice addition 👍

What is the purpose of "static internal" method if you nerver used it?

The generic error gona work for every kind of error? Like bugs, connection problems with db, etc ?

@jgoebel

2 жыл бұрын

yes, any error that is not anticipated, i.e. that is not an instance of ApiError will be caught

nice

why you return; empty just to stop the program instead of returning next(new ApiError(404,blabla)), is there any difference?

@jgoebel

2 жыл бұрын

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.

@privacypolicy9201

2 жыл бұрын

@@jgoebel so the middleware will stop passing to next() till that point?

thanks

@jgoebel

3 жыл бұрын

thx Konrad, you're welcome!

5:38 Thanks for point it out, I alway wonder why I can't console in nodejs

@jgoebel

2 жыл бұрын

👍

I like your stuff. I saw that you're German as well so Hallo von mir 👋

@jgoebel

Жыл бұрын

Thx, schöne Grüße nach Erfurt 😁

Is it acceptable to use ApiError inside services? Or is it intended to be used only in controllers?

@jgoebel

3 жыл бұрын

I would primarily use it in controllers because the service layer should only handle business logic

@turan_sultan

3 жыл бұрын

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

@jgoebel

3 жыл бұрын

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

@turan_sultan

3 жыл бұрын

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

subscribed

@jgoebel

3 жыл бұрын

thx

It's clear and simple but, when you work with async functions it all gets messy

bro i have .unshift error in my code plse help me out of it in express

@jgoebel

3 жыл бұрын

Hi Sumit, I don't think this is related to the error handling code in the video because there we do not use unshift

@sumitpandey6958

3 жыл бұрын

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.

@sumitpandey6958

3 жыл бұрын

Plse help me on that problem

@jgoebel

3 жыл бұрын

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

@jgoebel

2 жыл бұрын

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

@mohityadav21

2 жыл бұрын

@@jgoebel got it. Thanks

the github repo doesn't exist

@jgoebel

4 жыл бұрын

thanks for the hint. Sry. I forgot to make it public. Now it should work: github.com/productioncoder/express-error-handling

{2023-09-01}

zoom a bit more next time😅

@jgoebel

3 жыл бұрын

sure, will do next time