TritonDataCenter / node-verror

Rich JavaScript errors
MIT License
1.18k stars 61 forks source link

Adding isOperational property to VError #45

Closed goldbergyoni closed 6 years ago

goldbergyoni commented 7 years ago

Hi,

Following the best practices article, it resonates with me to decorate errors with boolean isOperational property so any exception thrower can flag whether this is trusted error that doesn't worth to restart the process for (e.g. user wasn't found in DB) or is it some unknown error that might leave our app in an incosistent state (e.g. some important object has an undefined property and each request fails).

Then, each app can have a centralized error handler which processes each Error and if isOperational===false or 'undefined' then the process will be terminated. This helps us not to restart because of simple and familiar error, only for severe or unkonwn errors.

When exceptions are chained (using a cause), the handler has to restart if one child Error (casue) is not operational so we may add property to VError.hasNonOperationalError which will recursively check whether any inner Error (cause) is not operational

Does it make sense? can I create a PR for that?

Y

jclulow commented 7 years ago

I think this is something for which you could use the VError#info() mechanism. For example:

var VError = require('verror').VError;

function
failing_function(cb)
{
    cb(new VError({ info: { fatalError: true }}, 'fatal error'));
}

failing_function(function (err) {
    if (err) {
        if (VError.info(err).fatalError) {
            console.error('FATAL');
            process.exit(1);
        }
    }
});

Note that the info object accumulates properties along the cause chain. If you don't set fatalError, then when you check for it via info(), it will be undefined. If it gets set to true anywhere along the cause chain, it will read as true at the top level.