using errors

Much error handling has to be tailored to the situation that suits it, at a minimum, you will want an overall error handler for an API call to handle unexpected errors and report them to the consumer and probably a log.


sometimes we can do something when an error occurs before it hits the default handler, in this case, we return cached data instead.


One important thing to note is the extra value that is added when using the Error class even when rejecting a promise.


This will mean that when we log out the error in the error handler we also get a stack trace, as when a new error is created it records the current stack.

In some cases, we may not be able to fix the problem but we may be able to add additional information to help us when reading the logs later.


now the log will contain the user id and save us some time when debugging later!

Some error cases may be something that we cannot do anything about but the user can, in this case, we are going to need to tell them about it, this hopefully saves us being contacted by the consumer/user and they can fix their own problem.


In this case, we create an additional error type that extends error so that we can bubble that up to be able to alert the user that their account is disabled.