How To Handle Errors in Node.js and TypeScript 

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.

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.

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 🎇

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.