node.js - Error handling different types of errors

Question

I'm writing a series of REST APIs in Express and want to write a robust and consistent way of handling errors and presenting them to the user. So far I'm using middleware that looks like the following:

app.use(function(req, res, next){
    res.render('404', { status: 404, error: 'not_found', error_description: 'the url '+req.url+' could not be found' });
});

app.use(function(err, req, res, next) {
    switch (err.name) {
        case 'CastError':
            res.status(400);
            return res.send({code:400, error: 'cast_error', error_description: err});
        default:
            console.log(err);
            return res.send({code:500, error: 'internal_error', error_description: 'something went horribly wrong!'});
    }
});

Now the problem comes in that errors can come from any part of the application. For example, Mongoose fires errors like 'CastError', there might be general system errors (unable to connect to the database) and there's also user validation errors.

Now some errors I want to present a message to the user (for example validation errors or telling them what was wrong with their API request), whereas others I want to hide from the user.

So looking at a validation error:

throw new Error('not a valid project id');

At the moment that'd just get caught as a generic 500 error and no useful message presented to the user. How can I differentiate the above error from a general system error so they can be handled differently? Is there an error type property I can make use of (perhaps err.name). If so, how do I use it?

Concept ideas (that obv don't work):

throw new Error('validation', 'not a valid project id');

Or

throw new Error('not a valid project id').name('validation');

Answer 1

Errors are objects and can be assigned additional properties. You could add more properties to an error after it has been constructed. Also note that the operand to throw doesn't have to be an Error, it can be any other object.

var validationError = new Error('Not a valid project ID');
validationError.type = 'validation';
throw validationError;

A better alternative is to use a custom error class inheriting from Error.

function ValidationError(message) {
    if(!(this instanceof ValidationError)) {
        return new ValidationError(message);
    }
    var err = this.err = Error.call(this, message);
    this.message = message;

    Object.defineProperty(this, 'stack', {
        get: function () {
            return err.stack; 
        }
    });

}
ValidationError.prototype = Object.create(Error.prototype, {constructor: ValidationError});

This approach lets you distinguish ValidationErrors from other errors by using the instanceof operator. This is an excerpt from a koa application:

app.use(function *() {
    try {
            if(this.method != 'GET') {
                yield this.connection.beginTransaction();
                yield *next;
                yield this.connection.commit();
            } else {
                yield *next;
            }
        } catch(err) {
            if(err instanceof ValidationError) {
                this.body = err.message;
                this.status = 422;
            } else {
                throw err; //let the framework notify the client of 500 Internal Server errors
            }
            if(this.method != 'GET') {
                yield this.connection.rollback();
            }
        }
});

Answer 2

You should consider using an existing npm module such as http-errors or boom. At least when throwing your own errors, these will make it easy to get good HTTP semantics in your responses.