Handling with the 'error' parameter inside a callback function in node.js I have multiple controllers and every controller has this error handler:

if (error) {
  res.render('error', {
     error: error
  });
}


Sometimes I have more than one:

exports.update = function(req, res, next) {
    MyModel.findById(req.params.id, function(error, event) {
        if (error) {
            res.render('error', {
                error: error
            });
        }
        else {
            event['active'] === false ? event['active'] = true : event['active'] = false;

            event.update({
                'active': event['active']
            }, function(error) {
                if (error) {
                    res.render('error', {
                        error: error
                    });
                }
                else {
                    res.end('Success!');
                }
            });
        }
    });
};


I have more than 30 controllers and this seems like an inefficient way of handling.
If all of your functions adhere to this pattern you can wrap them in,
you guessed it, another function:

defaultError = function(handler) {
    return function(error) {
        if (error) {
            res.render('error', {
                error: error
            });
        }
        else {
            return handler.apply(null, Array.prototype.slice.call(arguments, 1));
        }
    };
};


This uses the
special arguments object,
which has to be converted to an array before you can slice off the error object, and apply on the passed-in function.

Now the previously repetitive code gets a bit shorter:

exports.update = function(req, res, next) {
    MyModel.findById(req.params.id, defaultError(function(event) {
        event['active'] === false ? event['active'] = true : event['active'] = false;

        event.update({
            'active': event['active']
        }, defaultError(function() {
            res.end('Success!');
        }));
    }));
};


Now obviously the defaultError can also customize the rendered error,
so as long as error is in a fixed position in the call, this pattern
can be used to build a small control flow abstraction.

The cost here is a possible speed penalty due to the manipulation of arguments and the apply call.

If you had promises a generic error handler would be equally
viable, but it looks like that is not an option.