Define error-handling middleware functions explicitly (without arity detection)

[feross]

I propose adding an explicit app.error method for defining error-handling middleware functions:

app.error(function(err, req, res, next) {
  res.status(500).send('Something broke!');
});

Instead of:

app.use(function(err, req, res, next) {
  res.status(500).send('Something broke!');
});

It's so easy to forget the next argument when it's not being used in the body of the function, and that changes the whole meaning of the middleware. express is one of the only packages that has this pattern. Others that used this pattern in the past (i.e. superagent) have since removed it.

Furthermore, this clashes with popular linting rules like ESLint's no-unused-vars rule which enforce that all named arguments must be used in the function body. Users who see this rule and remove the un-unsed next parameter will be unwittingly changing the behavior of their program.

No one expects removing an unused parameter to change the behavior of a program.

app.use(function(err, req, res, next /* <-- unused, guess I'll remove this... */) {
  res.status(500).send('Something broke!');
});

The four argument middleware convention should be deprecated in favor of app.error, but support for it could remain for a long time, or even indefinitely. I just want to be able to recommend that folks use app.error going forward.

[wesleytodd]

This, this this! I have thought this for a very long time. The implicit behavior of the error handlers is confusing to beginners and advanced users alike. I would support making this to 5.0 and explicitly deprecating the old way, for future removal. And possibly even adding as a new feature in 4.0 as a point release. Thanks @feross for bringing this up.

[Fishrock123]

I think this is probably a Good Idea™.

Maybe we should do some assessment of how much app.use(function(err, req, res, next) {}) is used in the wild and see how viable deprecation would be for 5.0?

[wesleytodd]

My guess is that since it is the only way to handle errors it is used in EVERY express app :) Right?

I know for sure that I use it in all of my apps.

[jordonias]

It would have to be changed in the errorHandler middleware as well. If deprecated, new versions of the middleware would not work with Express 4. There may be some other modules as well.

[wesleytodd]

Do you have a link to the code that you are saying would need to change?

[jordonias]

https://github.com/expressjs/errorhandler/blob/master/index.js#L83

This is just an example. There is going to be other third-party modules that are going to have to be changed as well, and I'm not sure if it's possible to handle carefully.

[tunniclm]

This looks like a nice idea. The implicit error handler behaviour is one of the more surprising parts of the api imo.

[hacksparrow]

The interface looks lovely. I am assuming the extended example looks something like this:

app.error(function(err, req, res, next) {
  if (err.code === 404) res.status(err.code).render('404');
  else res.status(err.code).send(err.string);
});

[billinghamj]

Major 👍 to this - my linter complains about the unused parameter all the time even though I can't remove it.

[wesleytodd]

@billinghamj I use // es-lint-disable a bunch for this, but I think you should be able to do something like // eslint no-unused-vars: [2, { "args": "none" }] to specifically do just that one rule. I just hammer it with a full disable because I cannot remember that long argument line :)

[sjanuary]

This API is really nice 👍

[dlinx]

Nice option,
There is another option,

/* error parameter will be at end. To maintain standards*/
app.use(function(req, res, next, err) { 
  res.status(500).send('Something broke!');
});

Another one option. Using chaining to handle error. This will give power to handle error at all levels.

app.get('/',function(req, res, next) { 
  res.status(500).send('Something broke!');
}).error(function(err){
    /* Error Handler*/
});

[Zertz]

This is a neat idea, but it would have to be a feature because this is a gigantic breaking change. There are a lot of Express dependents out there and this breaks all of them, no exceptions.

Personally, I don't think deprecation is even appropriate.