Great video! You touched almost every aspect of error handling in Node.js and TypeScript. Creating an abstract class for custom errors is a fantastic idea! 🎉 However, I think having too many types of custom errors can be a bit overwhelming for developers to remember. Perhaps introducing a single AppError class with a custom error code along with the status code would be a great idea. For example, using enums for error codes like AUTH_ERROR could simplify things and provide better TypeScript support without the hassle of remembering different error types. Keep up the great work! 👏
Thanks for the feedback, Anurag. I have to well educate myself about that before talking about it and make valuable content out of it. I'll keep your request in mind.
the lack of runtime type safety has always been the deal breaker for me with typescript. to even simulate that you need libraries that are verbose and complex.
Sir, I understood the concept to good extent. But having to create so many discrete types of errors might become a repetitive process as errors can be of various format based on the API. E.g., { success: false, message: "Invalid user id."} and so on. The abstraction and type checking is absolutely great but I also went through another tutorial and they had defined a simple error handler without any subtypes but just taking custom string and status code i.e., return next(new ErrorHandler("Invalid user id", 400). Could you suggest which would be more practical to use as I am refactoring one of my projects and I want to implement the best option out there.
In case of “invalid user id”, it’s not yet another different type of error that you need to create a different class for it because it’s a bad request error with 400 status code. Remember in this solution you just change the message when you throw the error and instantiate the custom class. You can use the constructor to pass custom messages to customise the bad request errors. But in case of authentication errors, I don’t see any value from customising the error message, that’s why in the video I implemented a hard coded error message. The solution you suggested also works fine. Was it implemented with TypeScript or simple JavaScript? In the solution you suggested, you have to write a message and an error status code every time you instantiate the ErrorHandler. Imagine you have an error occurring for “user unauthenticated”. That message most likely won’t change, so it’s a repetitive code to write it every time you wanna throw an unauthenticated error. Also the developer might write any message and any status code without any warnings, which means less leverage of TypeScript’s power. That can also cause confusion for front end engineers. I used this style of error handling to harness the power of classes and OOP that is missing in JavaScript (it’s complicated in pure JS prototypes), which is in my opinion the intended way of using TypeScript. Which one more practical? You should evaluate that yourself. I can simply contrast different approaches and pros and cons of each. I don’t wanna be biased to one solution or another. To me personally I find this is the way that makes sense, because I always love my code to be expected and organized, but again it makes sense to me so I decided to share it. If you feel like implementing something else, of course feel free to do so.
@@markmaksi Okay, get it now. The tutorial I followed was using Typescript but my project is based on JS as of now. And I don't want to make that shift just yet because I am on vacation and might end up breaking the code. But I can see more and more sense in your approach now because I ended up repeating myself a lot of times as I was upgrading the error throwing mechanism in the entire backend. Thanks for the reply. This genuinely helped me. I will surely implement this for this refactoring project and as well as my future backend projects :)
Interesting stuff. I never got the hang of throwing and catching Errors as a way of managing code flow. I realize it's the done thing but I won't change my ways now. AFAIK, Promises and uncaught Errors go poorly together. If you don't catch the Error before it gets to the Promise, things stop. Since I don't want my server to stop, I consider Errors to be like nitroglycerin. Internally, I prefer to just use return codes, in the spirit of 'not-found', 'nothing-to-do' and 'unauthorized'. More complex than that: a return object, I guess. So it's like an Error but without the danger factor.
Well, I always do try/catch for promises to avoid the unhandled promise rejection error as you stated, and I throw a specific error. If it was a general error that I didn’t handle, the middleware will do the job and throws 500 internal error or 400 bad request. Returning objects isn’t wrong, but gets repetitive very quickly and also no centralised place to handle errors. I’m not fixated towards one approach or another. I prefer to learn what every approach has to offer.
@@markmaksi "gets repetitive" That's no lie! The nature of our stuff is that these are flung out into the world so the idea of centralization is different than you might imagine. We spend a lot of thought on sifting events to be explicitly sent upstream. "try/catch for promises" That makes sense. It seems strange to have to do that, no? I never got the hang of using the 'reject' of a Promise. If it failed, we resolve with an error code in the status object.
Yes of course! I am currently planning for 2 videos that aim to teach how to prepare production workflow: next.js app > write tests (there’s a playlist on my channel) > create CI pipeline using github actions > docker container > deploy to AWS EC2 instance. It’s all made for beginners. After that I will make that video that you have just requested. :)
![Typescript API in NodeJS / Express in Depth [Part 1]](http://i.ytimg.com/vi/NYZKUTGC51g/mqdefault.jpg)
Nice work on this complex topic. Perfectly Explained. Thank you
Great video! You touched almost every aspect of error handling in Node.js and TypeScript. Creating an abstract class for custom errors is a fantastic idea! 🎉
However, I think having too many types of custom errors can be a bit overwhelming for developers to remember. Perhaps introducing a single AppError class with a custom error code along with the status code would be a great idea. For example, using enums for error codes like AUTH_ERROR could simplify things and provide better TypeScript support without the hassle of remembering different error types.
Keep up the great work! 👏
Thank you sir i have been using this my projects
sir plz bring aws cdk typescript video explaining all concepts from basic
Thanks for the feedback, Anurag. I have to well educate myself about that before talking about it and make valuable content out of it. I'll keep your request in mind.
great sir 👍
the lack of runtime type safety has always been the deal breaker for me with typescript. to even simulate that you need libraries that are verbose and complex.
Wonderful explanation.
Great explanation brother.
Sir, I understood the concept to good extent. But having to create so many discrete types of errors might become a repetitive process as errors can be of various format based on the API. E.g., { success: false, message: "Invalid user id."} and so on.
The abstraction and type checking is absolutely great but I also went through another tutorial and they had defined a simple error handler without any subtypes but just taking custom string and status code i.e., return next(new ErrorHandler("Invalid user id", 400).
Could you suggest which would be more practical to use as I am refactoring one of my projects and I want to implement the best option out there.
In case of “invalid user id”, it’s not yet another different type of error that you need to create a different class for it because it’s a bad request error with 400 status code. Remember in this solution you just change the message when you throw the error and instantiate the custom class. You can use the constructor to pass custom messages to customise the bad request errors. But in case of authentication errors, I don’t see any value from customising the error message, that’s why in the video I implemented a hard coded error message.
The solution you suggested also works fine. Was it implemented with TypeScript or simple JavaScript?
In the solution you suggested, you have to write a message and an error status code every time you instantiate the ErrorHandler. Imagine you have an error occurring for “user unauthenticated”. That message most likely won’t change, so it’s a repetitive code to write it every time you wanna throw an unauthenticated error. Also the developer might write any message and any status code without any warnings, which means less leverage of TypeScript’s power. That can also cause confusion for front end engineers.
I used this style of error handling to harness the power of classes and OOP that is missing in JavaScript (it’s complicated in pure JS prototypes), which is in my opinion the intended way of using TypeScript.
Which one more practical? You should evaluate that yourself. I can simply contrast different approaches and pros and cons of each. I don’t wanna be biased to one solution or another. To me personally I find this is the way that makes sense, because I always love my code to be expected and organized, but again it makes sense to me so I decided to share it. If you feel like implementing something else, of course feel free to do so.
@@markmaksi Okay, get it now. The tutorial I followed was using Typescript but my project is based on JS as of now. And I don't want to make that shift just yet because I am on vacation and might end up breaking the code.
But I can see more and more sense in your approach now because I ended up repeating myself a lot of times as I was upgrading the error throwing mechanism in the entire backend.
Thanks for the reply. This genuinely helped me. I will surely implement this for this refactoring project and as well as my future backend projects :)
@@whatinquest you’re very welcome. Glad you enjoyed the video. Enjoy the vacation and wish you a happy new year!
@@markmaksi Happy new year to you too 🎇
Interesting stuff. I never got the hang of throwing and catching Errors as a way of managing code flow. I realize it's the done thing but I won't change my ways now.
AFAIK, Promises and uncaught Errors go poorly together. If you don't catch the Error before it gets to the Promise, things stop. Since I don't want my server to stop, I consider Errors to be like nitroglycerin.
Internally, I prefer to just use return codes, in the spirit of 'not-found', 'nothing-to-do' and 'unauthorized'. More complex than that: a return object, I guess. So it's like an Error but without the danger factor.
Well, I always do try/catch for promises to avoid the unhandled promise rejection error as you stated, and I throw a specific error. If it was a general error that I didn’t handle, the middleware will do the job and throws 500 internal error or 400 bad request.
Returning objects isn’t wrong, but gets repetitive very quickly and also no centralised place to handle errors.
I’m not fixated towards one approach or another. I prefer to learn what every approach has to offer.
@@markmaksi "gets repetitive"
That's no lie!
The nature of our stuff is that these are flung out into the world so the idea of centralization is different than you might imagine. We spend a lot of thought on sifting events to be explicitly sent upstream.
"try/catch for promises" That makes sense. It seems strange to have to do that, no?
I never got the hang of using the 'reject' of a Promise. If it failed, we resolve with an error code in the status object.
Would like you to take us through handling user authentication in express, node and typescript, and using sequelize postgres. Thank you
Yes of course! I am currently planning for 2 videos that aim to teach how to prepare production workflow: next.js app > write tests (there’s a playlist on my channel) > create CI pipeline using github actions > docker container > deploy to AWS EC2 instance. It’s all made for beginners. After that I will make that video that you have just requested. :)
@@markmaksi Thank you. Looking forward for more. God bless your for your commitment and sacrifice.
Awesome video.
Best 🎉
Amazing explanation.Tky