DEV Community

Central Error Handling in Express

Chinedu Orie on July 15, 2019

Express is a fast, unopinionated, minimalist web framework for Node.js - docs Error handling is a routine that one can not do without while buil...

Read full post

Jakub • Jan 21 '20

Hello,
I really like this post as I'm learning a better way of handling errors.

I have a question about when you add in the .catch(err) { next(err) }
Is this actually throwing out an error from server or I should still use like you did before
throw new ErrorHandler(500, 'Internal server error');

Or that next(err)is doing it?

I just not get that and I would like to understand it.

I have an example of how I used:

async getAll(req, res, next) {
        try {
            const profiles = await db.Profile.find({});
            if (!profiles)
                throw new ErrorHandler(404, "No profiles are found!");

            res.send({
                profiles
            });

            next();
        } catch (err) {
            next(err);
        }
    },

Thanks for help :)

trannguyen61 • May 6 '20

Since getAll is a middleware, it must call next() to tell the server to continue processing the next step after that, or else it will be blocked and never return any responses to the client. The error thrown in try block is then caught in catch block, through the name of err.
Therefore, calling next(err) means passing err to the next error-handling middleware while keeping the flow of your app running.

Brian • Dec 24 '19 • Edited

The best error handling mechanism I've seen so far. I have a question though.

I understand that i have to require this in the index file:

const { handleError } = require("path-to-code")

Will I have to include this code

const { ErrorHandler } = require("path-to-code");

in every file where I need to handle errors apart from the index file?

Chinedu Orie • Dec 25 '19

It's like any other module, you will have to require/import it anywhere you need to use it. No specific exceptions, it depends on the use case.

Brian • Dec 25 '19

Thank you so much

Thinh Nguyen • Nov 8 '19 • Edited

Great Article, Thanks

btw, I got a small question in this own Error class :

class ErrorHandler extends Error {
  constructor(statusCode, message) {
    super();
    this.statusCode = statusCode;
    this.message = message;
  }
}
module.exports = {
  ErrorHandler
}

Why we have to write like this (1)

super();
this.message = message;

but not like this (2)

super(message);

Actually, I wrote like (2) and then my own class lost a message property

It only comes back when I change it to (1).

What is the difference between them ?

Thanks,

Chinedu Orie • Nov 8 '19 • Edited

The super() method is used when a class (child) inherits from another class (parent).
The super() method provides a means of syncing the child's constructor to the parent's constructor.
Let me illustrate with an example

class Foor {
    constructor(name) {
        this.name = name
   }
    printName = () => {
      console.log(this.name);
   }
}

class Bar extends Foo {

     constructor(name) {
         super(name)
   }
}

const bar = new Bar('Test');

bar.printName() // Test

Now, looking at the code above,Foorequires anameto be passed to its constructor in order to function, whenBarinherited fromFoo, there's no way thenamecould be passed down toFooif not with thesuper()`

So, in relation to the snippet that you shared above, you are passing the message to the parent which in this case is Error, that way the child ErrorHandler has no access to message

I hope this helps.

Alexey Vorobyov • May 25 '20

Is there a necessity in Bar constructor at all?
You just pass the same Test value to the parent class ultimately. In this case
there is no need to a constructor at all I assume and Eslint should also hint about it.

Ogbonna Basil • Jul 16 '19 • Edited

This is cool,

Just one opinion, i feel it should be expanded to be not just Error Handler but statusHandler

```
class statusHandler extends Error {
constructor(statusCode, message, data) {
super();
this.statusCode = statusCode;
this.message = message;
this.data = data || null

}
}
module.exports = {
statusHandler
}




Likewise for handleError but generally this approach is effectively DRY. Nice one

Chinedu Orie • Jul 16 '19

Just like Express is unopinionated, how you apply the concept in the article is also unopinionated. And except I do not understand you clearly, it'd not make sense semantically to throw a success response as an error. Thanks for sharing your views.

Dimitri KOPRIWA • Feb 27 '20

Hi and thanks for this article, I have tried to implement it and instead of having the errorMiddleware called when I throw new ErrorHandler(500) within my route, I have in the console: (node:16482) UnhandledPromiseRejectionWarning: Error: Server Error what part did I miss? thanks

Yuanpeng Zheng • Apr 14 '20

Great post. Buddy. Just got one question here.

const validateUser = async (req, res, next) => {
  try {
    .....
    next()
  } catch (error) {
    next(error)
  }

  res.on('finish', () => {
     // How could you handle the error here for express? Thanks. 
  }
}

Ajay Sainy • Jul 26 '20

Thanks for a useful post. One question on usage of validateUser method. How do we use that method in lets say any PUT path that validates a user?
Simply calling validateUser(req, res, next) is causing the error Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client in the code below validateUser call that assumes the user is already validated.

I am guessing this is happening because express does not immediate terminates the request processing after the response has been sent to the client.

Chinedu Orie • Jul 30 '20

I think your guess is right. Sometimes it happens if a return statement is skipped somewhere, so the execution continues after the first error encounter

Rodrigo Abbás • Jul 27 '20 • Edited

Hi Chinedu,

Thank you very much for your post! This is what I've been wanting to implement, but somehow I couldn't figure out a simple way.
I adapted it a little bit to my code but applied the same principle you are describing.
Again, thanks man!
Cheers!

Ady Rahmansyah • Mar 28 '20

Thank you. It's really helpful

Rajesh Barik • May 21 '20

Hi, This is an awesome article. I just have one problem. I implemented it, but whenever I use this throw error, my server crashes with error throw er; // Unhandled 'error' event. What did I do wrong ? Could you please help me ?

Leiver Moreno • Feb 28 '20 • Edited

Just what I was looking for, I'm learning Express.
Just one doubt, what in case of, for example, a database error? Which is no enclosed by an if statement and there is no error throw for it. Therefore the express error middleware is called and ErrorHandler object is instantiated with code and message set to undefined.

The solution I propose is to add an if statement in the ErrorHandler constructor to check if the given values are undefined. Let know your opinion and if I'm wrong.

OmanCoding • Dec 12 '19

Thank you for the article, I learned something.

I have question, how does Express know that next(error), should be passed to the Error Handling middleware (which has 4 arguments)?

If there is a middleware that has (res, req, next) that was sat up before the Error Handling middleware, will it get first to handle the error?

Nasser

Leiver Moreno • Feb 29 '20 • Edited

This happens because even if you do not configure a middleware for error handling, express does it internally for you, so when an error occurs, all subsequent middlewares are skipped until the error handling middleware. How does express know what this middleware is? Because it has four arguments, error, req, res, next.