bodenr / errors Goto Github PK

There is an exported method called isError(): https://github.com/bodenr/errors/blob/master/lib/errors.js#L112

This should be added to the docs as it's very useful for differentiating between errors created by this module and other errors.

See http://stackoverflow.com/questions/37070083/error-objects-native-and-custom-how-to-tell-the-difference.

example:

errors.create({ name:'MyHttpRequestError', status: 400, ... });
errors.MyHttpRequestError()

outputs:

{
  "name": "MyHttpRequestError",
  "code": 601,
  "status": 400,
  ...
}

The HttpXXXError instances of have a "code" property of type string, where newly created errors would have a type of number (starting at 600).

example:

errors.Http401Error({message:"Expired Token", expired:someDate});

Would set the message property, as well as including an expired property on the output. I find the act of sending multiple strings to the constructor a bit disturbing for example.

By including express in the list of dependencies in package.json, it makes express a required dependency of the package. That means that the checks in lib/errors.js will always load the errorHandler middleware despite the attempts to only provide the feature if the express module is available.

I really like the feature of express being conditionally loaded as then this library can be used outside of node.js too. Was it intended to make express a requirement of this package?

The last release bumped the major version number, but it's not obvious to me why, and there doesn't appear to be a changelog. What is the possible break?

Code:

var errors = require('errors');
errors.create({ name: 'FooError' });
throw new errors.FooError('custom message');

Output:

myndzi@tetrisguide:~/foo$ node -v
v0.10.33
myndzi@tetrisguide:~/foo$ node test

/home/myndzi/foo/test.js:7
throw new errors.FooError('custom message');
      ^
Error: custom message
    at Object.<anonymous> (/home/myndzi/foo/test.js:7:7)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:906:3

myndzi@seckzi:~/conjoined$ node -v
v5.3.0
myndzi@seckzi:~/conjoined$ node errorstest.js

/home/myndzi/conjoined/errorstest.js:7
throw new errors.FooError('custom message');
^
Error
    at Object.<anonymous> (/home/myndzi/conjoined/errorstest.js:7:7)
    at Module._compile (module.js:398:26)
    at Object.Module._extensions..js (module.js:405:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Function.Module.runMain (module.js:430:10)
    at startup (node.js:141:18)
    at node.js:980:3

I want to wrap a low-level error with another error, and have errors's "stack" setting to affect how it's printed.

var fs = require('fs');
var errors = require('errors');

function doSomeImportantThing(filename, cb) {
  lowLevelFileSystemThing(filename, function(err) {
    var newErr =  new (errors.find('SomeImportantFailure'))({
      cause: err
    });

   console.log(newError.toJSON());
  });
}

stack is false:

{
   "cause": {
     "message": "lowLevelFileSystemThing failed foobarred $filename"
   },
  "code": "600",
  "message": "SomeImportantThing Failed",
  "name": "SomeImportFailure"
}

stack is true:

{
   "cause": {
     "message": "lowLevelFileSystemThing foobarred $filename",
     "stack":  "…"
   },
  "code": "600",
  "message": "SomeImportantThing Failed",
  "name": "SomeImportFailure",
  "stack": "…"
}

The current output prints the "stack" in all cases.

var errors = require('errors');

errors.create({
  name: 'ValidationError',
  defaultMessage: 'Validation error',
  defaultExplanation: 'Some properties are not valid',
  defaultResponse: 'Resend the object with valid properties',
  parent: errors.Http400Error
});

// Status property is 500 instead of 400.
console.log(new errors.ValidationError())

Is there a way to fix this?

I'm working on a project using keystone.js. In case you don't know it, it's an express-based CMS. I wanted to integrate the 'errors'-module, however noticed I can't use errors.errorHandler middleware. I think this is due to https://github.com/bodenr/errors/blob/master/lib/errors.js#L643
It checks for the presence of 'express' or 'connect' and only exports errorHandler in case one of those is found. However since my project doesn't depend on express directly neither express nor connect are found and the errorHandler isn't exposed. Obviously I could add express to my dependencies, but I'd rather not, since it isn't used anywhere else.

Do you know of a workaround? ATM I simply don't use any of the express integration, but that's a bit of a shame IMO.

Is there a way to override only a specific default property? Since in some cases I just want to override the explanation or response.

var errors = require('errors');

errors.create({
  name: 'ValidationError',
  defaultMessage: 'Validation error',
  defaultExplanation: 'Some properties are not valid',
  defaultResponse: 'Resend the object with valid properties',
  parent: errors.Http400Request
});

var validationError = new error.ValidationError();

// TypeError: Cannot assign to read only property
validationError.explanation = 'My new explanation';

It would be nice to have the message string as a template against the other properties of the object... (suggest ES6 string template format, lodash has an implementation)

example:

errors.create({
  name: 'DocumentNotFound',
  message: 'The document "${document}" was not found.'
});

console.log(new errors.DocumentNotFound({ document: 'path/to/document.ext' }))

would output:

code: 6xx
name: 'DocumentNotFound'
message: 'The document "path/to/document.ext" was not found'

Idea burrowed from error/typed

//using lodash's _.template
  ...
  if ((/\$\{[^\}]+\}/).test(this.message)) {
    this.message = _.template(this.message, this);
  }
} //end of constructor method

Making lodash a dependency without a version specified to allow for npm dedupe in a hosting package to always work, with a very slim risk of an incompatible version.