Really like your list! However I have to ask your reasoning behind item no 30.
I have used middlewares designed only for errors in express and serverless node applications and it had a really positive experience. This approach works quite well as it allows your can check if the error is a custom one and then pass the extra params that will help you debug the app. Otherwise it will be a standard error and won’t change your apps behaviour. Thoughts?
Thanks Harris! I believe - the following article sums it well:
It is a wrong practise to handle errors within Express middleware — doing so will not cover errors that are thrown in non-web interfaces.
Without one dedicated object for error handling, greater are the chances of important errors hiding under the radar due to improper handling. The error handler object is responsible for making the error visible, for example by writing to a well-formatted logger, sending events to some monitoring product like Sentry, Rollbar, or Raygun
Really like your list! However I have to ask your reasoning behind item no 30.
I have used middlewares designed only for errors in express and serverless node applications and it had a really positive experience. This approach works quite well as it allows your can check if the error is a custom one and then pass the extra params that will help you debug the app. Otherwise it will be a standard error and won’t change your apps behaviour. Thoughts?
Thanks Harris! I believe - the following article sums it well:
medium.com/devcbeirut/error-handli...