How To Handle Errors in Node.js and TypeScript

Learn to use the type checking system of TypeScript to handle errors in Node.js like a senior engineer. We're going to build an abstract class that acts as a blueprint for custom error classes, leaving no way for other engineers working on the same codebase to write inconsistent or repetitive code.
#javascript #nodejs #errorhandling #expressjs #api
- Github repo: github.com/mmaksi/nodejs-erro...
- Hashnode article: markmaksi.hashnode.dev/how-to...
- Stackoverflow discussion: stackoverflow.com/questions/4...

[@aadilminhaz1637]

Nice work on this complex topic. Perfectly Explained. Thank you

[@brianbutton6346]

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.

[@eatcode4530]

Wonderful explanation.

[@prashlovessamosa]

Great explanation brother.

[@AnuragMishra-ws4zc]

great sir 👍

[@songs123d]

Awesome video.

[@smoked-old-fashioned-hh7lo]

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.

[@AnuragMishra-ws4zc]

sir plz bring aws cdk typescript video explaining all concepts from basic

[@markmaksi]

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.

[@eatcode4530]

Would like you to take us through handling user authentication in express, node and typescript, and using sequelize postgres. Thank you

[@markmaksi]

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. :)

[@eatcode4530]

@@markmaksi Thank you. Looking forward for more. God bless your for your commitment and sacrifice.

[@eduxjam]

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.

[@markmaksi]

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.

[@eduxjam]

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

[@markmaksi]

@@eduxjam you’re very welcome. Glad you enjoyed the video. Enjoy the vacation and wish you a happy new year!

[@eduxjam]

@@markmaksi Happy new year to you too 🎇