Is it alive?

[wingedfox]

Hi,

I'd like to add some features like nested errors and pretty error printing, but not sure whether the lib is alive.

Thanks.

[andrezsanchez]

Yes it's still alive. I just haven't had to add any features (and I did take a break from web dev related things for a while admittedly).

One of the motivations behind this library is that every other Error sub-classing library I could find was feature-ridden, when all I wanted was a bare minimum subclass. That being said, people do want extra features for good reasons. If possible I would like this library to be set up such that if someone has a feature they really want, they can use this and build their functionality on top of it and make that a library, without forcing everyone else to have a ton of functionality they don't need.

How would each of these features work in terms of API? I feel like the pretty printing could be done easily here by allowing the user to pass a custom print function.

[wingedfox]

Thank you for reply.

I definitely agree that the feature-rich error processing library will make it quite heavy in runtime.
But I need to mention that there are the features which are absolutely necessary and could not be implemented outside the library core.

For example:

1. Error nesting - it's absolutely necessary to track errors causes, e.g. 'request processing failed because nested request has failed' (https://github.com/mdlavin/nested-error-stacks)
2. Extended error constructors - it's often required to represent error with additional info, like for HTTP error it's often necessary to provide URL of a failed request and failure details (http://azimi.me/2015/09/23/high-custom-error-class-es6.html)
3. Error pretty-printing is essential for custom errors with additional payload because error should properly serialize itself to json when logged with winston or bunyan (http://stackoverflow.com/questions/18391212/is-it-not-possible-to-stringify-an-error-using-json-stringify)

Hope, you'll find these reasons important to extend the library and accept PR's, addressing these issues.

[andrezsanchez]

Thanks for the suggestions. I've thought about this some, and I agree that these would be great to have, and that they could be done without causing bloat.

I still feel like most of these can be implemented by adding some sort of hooks into the code. What this library does currently is:

• Returns a new class with the prototype set up properly in generic JavaScript
• Capture the stack
• Set the inspect function to display our error properly in the terminal
• Correct the V8 error message to use our own error name (though this seems to not working at the moment after experimenting with it just now... I will look into this)

The features you have suggested could be implemented by allowing properties (something like nestedError or childError) to be set on the prototype and by allowing a custom stack format to be written upon throwing.

Keep in mind though that the way that the stack is formatted varies across environments, as Error#stack is unspecified.

I just pushed a couple of commits that moves some functionality to functions so that they can be overwritten, though the constructor will still need to changed to allow the constructor arguments to be consumed.

What are your thoughts on this?

[wingedfox]

Thank you, this definitely makes sense.
I've added PR with the discussed features, please take a look.

Here's the usage sample

var E1 = new CustomError('E1');
var E2 = new CustomError('E2', E1);
var E3 = new CustomError('E3', E2, function (message, code) {

    this.code = code;
    this.toString = function () {
        return `[${this.name}:${this.code}] ${this.message}`;
    }
    this.inspect = function () {
        return `[${this.name}:${this.code}] ${this.message}`;
    }
});

var E4 = new CustomError('E4', E3, function (message, code) {
    this.inspect = function () {
        return `[${this.name}:${this.code}] ${this.message}; Caused by ${this.nested}`;
    }
});


var e1 = new E1('test1');
var e2 = new E2('test2');
var e3 = new E3('test3', 3);
var e4 = new E4(e3, 'test4', 4);
var e5 = new E4(new Error('test'), 'test5', 5);

console.log(e1, JSON.stringify(e1));
console.log(e2, JSON.stringify(e2));
console.log(e3, JSON.stringify(e3));
console.log(e4, JSON.stringify(e4));
console.log(e5, JSON.stringify(e5));

[wingedfox]

So, what do you think?