Central Error Handling In NodeJS and TypeScript

how is it going welcome to borderless engineer where we talk about web development and software architecture in today's subject we're going to discuss error handling now error handling is something we all have to deal with everybody has earth this is inevitable the question is what do you do with them so today's content is going to be split into two parts the first part is about why do you need central error handling how do you achieve that how do you distinguish between types of errors what do you need to do when actually receiving an error what are the next steps and the second the second part is really just taking all that all those concepts and showing an actual example of how that works in node.js now if you're not a node.js developer don't shy away from this you can still take the same concepts and probably apply them to your language so the first question i think we should try to answer is why do we even need a central error handling mechanism why do we need it to be central why can't we just have it wherever the air happens and the reason is quite simple the reason is because there are many places where you can simply forget to catch the air and the air will be just thrown out there and if you don't have anything to catch that error then you can't do anything about it and this point really leads us to the goal of error handling in general when we're thinking about the goal of error handling and what do we need to do to achieve a solid error handling infrastructure there are two sides to this the first side is what do you do with the error so there is an error you don't want it to just sit out there and wait for the developer to maybe notice there is an error especially if you're working with distributed systems where you can have tens of thousands of machines and you don't really know what's going on in any particular machine so you need to have a higher level of observability of what happens in your system and in order to do that you need to take these errors and send them to a log provider and then what you can do is you can actually set up alerts for them as well so next time an error happens you will be immediately alerted in slack or on pagerduty on your email or whatever and then you can go ahead and fix that error immediately so that is the first side to it the second side to this is the application side and the application side means what does the application do when an error happens and in order to understand that we have to make a distinction between different type of errors because you don't always want to do the same thing when an error happened so a useful distinction that's also very prevalent out there is the distinction between programmer errors and operational errors let's first talk about programmer errors so what are they programmer errors are essentially bugs so any bug that you have in a system then it essentially can be classified into a programmer error so these are one type of errors now operational errors are the exact opposite in the way of intent so programmer errors are not intentional we never intended for an error to happen and it happened but operational errors are intentional we wanted an error to be raised for very different reasons so it can be something like api validation where the user sent the wrong input for the api or it can be something like reaching a certain limit so these are the second type of errors operational errors and the way we handle these errors is very different first let's talk about how to deal with programmer errors and this really depends on whether you have a stateful service or a stateless service and the reason i make this distinction is because if you have a stateful service and an error happens and you capture that error and now you have to decide what to do with the application then if you don't restart it then the application is going to be in some sort of an intermediate state with the user state mixed in because maybe it's not been cleaned up it's stopped in the middle we can't really know and there are many things that can just go wrong that's why if you have a stateful service or even if you're using some state and you don't want to take risks then you're probably better off by just doing a graceful restart dealing with operational errors is much easier because you don't have the risks of having your application in an inconsistent state or in a corrupted state so what you want to do is just take the air and then you can send it to a logs platform or maybe you can gather metrics on it and you can do a lot of different things with it once it's centralized and since it's logs we're talking about it's only appropriate to mention core logix which are the sponsors of this and also is the company i work for so if you're looking for an observability platform make sure you check it out so after talking about the principles of error handling now we can jump into the code and take a look at an actual example of how this works before we start with the code example i want to give a quick shout out to jay huang actually this is where i first learned about this he has an article in toptile called how to build a node.js error handling system so i highly recommend it's great article and thank you jay for the inspiration to actually learn this and make this for showing the example i'm going to use the no type script starter package it's a package on github that i published it has node.js and tab script but it also has a bunch of different things but really we're going to use it because it has air handling infrastructure and it also has some examples about this error handling so let's take a look at what's going on here the first thing you want to do when creating your error handling infrastructure is create your own kind of error that fits your need so as you can see here i created base error that actually extends the error class of javascript and i give it a few properties i give it a log and a method name because i like to send logs with their method name so if i have a bug i know exactly where to look for http code and the last and very important piece and probably the most important piece piece is whether this is on operational error or not so this will help us later decide what to do with this error and as you can see here in the implementation we've extended the air object and this is how you do it and we also capture the stack trace so this way you can get the error with the full stack trace and everything so this is our base error we're going to look in just a second on how we actually invocate that error and how we use it so we have the base air then what you want to do is you want to create an error handler so here's an error handler this is how it looks like and what we have here is pretty much their handler has a logger and it has two methods one is handleair it accepts an error and what it does is that it simply logs the error so here you can do even more things you can log the error then send email then send notification then do x so you can do many many different things there because eventually everything will come down to this method and then you have another method called is trusted error and what this method does is pretty much it checks first whether this is an instance of the base error because if it's not the instance of the base error then it probably it's not an operational error you it hasn't been invoked intentionally and then the second thing we check is that it's also an operational error and we're going to use this method later let's now go into the appts and see what we need to do in order to make this actually a central air handler so up until now we created the baser the error handler now what we have to do is actually register this as the middleware so as you can see here this is what we've done and the error middleware is pretty simple it checks whether it's an operational error if it's not then it's moving to the next and the next middleware pretty much or which is gonna be pretty much the uncut exception one we're gonna see later and then if it's an operational error all we're gonna do is simply log it so here is where we make the distinction between go ahead and restart or go ahead and doesn't restart when it comes to our express middleware but not everything is gonna be caught in express certain things are going to be uncut so this is what we add this one here so we listen to all the uncut exceptions pretty much in node.js and then what we do is first handle the exception go ahead and we log it we do anything that's in the handle our logic and then we check if it's a an operational error or not and if it's not an operational error we simply exit the process which will lead to a restart in in the kubernetes faster usually or in the dark you're working with so usually you have some sort of auto restart on a process exit and so you want to implement that as well in order for it to actually work so that's what you have in the app ds so now we've registered the global error handler this is pretty much everything you need to do in order to register it but i also want to show you that you can create more type of errors like this so here we have the base error right and the base error is is one type of error but we can also have another one like api error and then in our app we can make certain certain dis distinguishments between these two just like i did so i'm going to show you that so let's take a look at an example we have our api here this api has a certain route does some validation and then it installs something so we click here and we see that it moves us to a controller so the controller has an install something function and then it calls the save in db which comes from a service so let's take a look at the service and we're going to go back and look at the controller in just a second but essentially what we have here is a service it has a function called savingdb and first it checks if it's valid so there's no actual code here it's all kind of like pseudo code but if it's not valid it throws an api error okay on the other hand we have a try and catch and on the catch here we throw a base error now what's the difference here here's the difference if you have a route and then you check for validity of something you want to actually go ahead and notify the client and maybe have that in your response and tell them look field x is not valid or this is what happened but when you have a catch error this can happen for many different reasons you don't want to send it to the send it to the client so for this reason for me what i found that works the best is making making the distinction between api errors and normal errors and this way you can send all the api errors to the client and then you have different type of errors for yourself so you can log them and then view them later so the reason why we wanted to make this distinction here is actually for the controller because now that we've thrown a specific error we can go to the controller and see that in the catch clause what we have here is that first we check if the error is an instance of the api error if so make the message the error message and if not then just have a generic error for the user so this is how i like to use this you can use this in many different ways the principle is the same of catching the errors and doing something meaningful with them and that's it for this video i really hope you liked it and really hope you learned something new and if you did and if you liked it make sure you like comment share this share this with your friends and of course subscribe to the channel to get more content just like this thank you so much for watching

Channel: WebDevLog

Views: 8,859

Keywords:

Id: kQO2ZCboIAg

Length: 11min 10sec (670 seconds)

Published: Thu Jan 13 2022