search

TritonDataCenter / node-verror

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

info: comparing `verror` and `@Netflix/nerror` #75

Closed trentm closed 4 years ago

trentm commented 4 years ago

(It is perhaps a little odd that I opened this as an "issue". I wanted to record this somewhere associated with the project, so here it is. Because there isn't a thing to complete/resolve here, I propose to close this issue soon.)

Comparing verror and @Netflix/nerror

A while back Netflix did a "friendly" fork of https://github/joyent/node-verror to https://github.com/Netflix/nerror. Its readme includes:

We hope in the future after the initial development period we can seek convergence between the two projects.

I've been a user of verror for years as an employee of Joyent and have been around for its entire development and have made some small contributions to it. It's primary author, davepacheco, no longer works at Joyent. As part of moving Joyent code reviews from a Gerrit instance to GitHub PRs I was taking a look at some Gerrit CRs for node-verror. In particular there are two GH issues, two PRs, and three CRs (some closed, some not) regarding VError usage of printf that led to options.skipPrintf and PError support in @Netflix/nerror and this PR for the same in verror. See https://github.com/joyent/node-verror/issues/63 for current discussion on that.

So how do these two modules compare?

nerror has not broken compatibility with verror

That's good! If I run nerror's test suite against verror/lib/verror.js it passes after I comment out the test cases for new functionality added to nerror.

That "new functionality" is:

verror tests pass using nerror/lib/verror.js

This is good too. If I run verror's test suite against nerror/lib/verror.js it works after these trivial changes:

diff --git a/package.json b/package.json
index 763a64f..4011511 100644
--- a/package.json
+++ b/package.json
@@ -10,7 +10,8 @@
        "dependencies": {
                "assert-plus": "^1.0.0",
                "core-util-is": "1.0.2",
-               "extsprintf": "^1.2.0"
+               "extsprintf": "^1.2.0",
+               "lodash": "^4.17.15"
        },
        "engines": [
                "node >=0.6.0"
diff --git a/test/tst.multierror.js b/test/tst.multierror.js
index a63125d..5453bc0 100644
--- a/test/tst.multierror.js
+++ b/test/tst.multierror.js
@@ -95,11 +95,11 @@ function main()
        /* errorForEach */
        mod_assert.throws(function () {
                console.error(errorForEach());
-       }, /^AssertionError.*: err must be an Error$/);
+       }, /^AssertionError.*: err must be an Error but got .*$/);

        mod_assert.throws(function () {
                console.error(errorForEach(null));
-       }, /^AssertionError.*: err must be an Error$/);
+       }, /^AssertionError.*: err must be an Error but got .*$/);

        mod_assert.throws(function () {
                console.error(errorForEach(err1));
@@ -111,7 +111,7 @@ function main()

        mod_assert.throws(function () {
                console.error(errorForEach({}, function () {}));
-       }, /^AssertionError.*: err must be an Error$/);
+       }, /^AssertionError.*: err must be an Error but got .*$/);

        accum = [];
        doAccum = function (e) { accum.push(e); };

In other words:

How does nerror differ?

These are my opinions.

Pros:

Cons:

Questions:

trentm commented 4 years ago

I'm closing this. It was informational.

richardscarrott commented 4 years ago

@trentm I absolutely love VError and I'm surprised it's not more commonly used. As you've been around since the beginning (and at the risk of sounding silly?), it's alway bothered me that I don't know what the 'V' stands for, do you know?

kayomarz commented 4 years ago

This is not an answer for what "V" stands for but I also wanted to chime in to say that this is a very useful library.

It would be a nice addition to the ES standard as it allows for systematic recording of a chain of errors which when reported correctly can simplify finding the root cause of a problem.

On Sun, Jun 21, 2020 at 8:07 PM Richard Scarrott notifications@github.com wrote:

@trentm https://github.com/trentm I absolutely love VError and I'm surprised it's not more commonly used. As you've been around since the beginning (and at the risk of sounding silly?), it's alway bothered me that I don't know what the 'V' stands for, do you know?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/joyent/node-verror/issues/75#issuecomment-647136546, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABCICNMCBWA7MB72G3DSSLRXYLI7ANCNFSM4JEZDTXA .

davepacheco commented 4 years ago

@richardscarrott The story of the name is a little silly: the first purpose for VError was to provide a printf-like format string for constructing errors. (Causes and informational properties came later.) In C, a bunch of the printf-related functions use v in the name (e.g., vsnprintf) to tell you that they take C-style varargs. As I recall, that's all there was to it -- I picked the v prefix because it reminded me of all the printf-like formatting functions with variable arguments. (The reason I say it's a little silly is that the C functions that look like printf all don't have a v in the name -- the v really refers to a very C-specific way of processing varargs.)

@richardscarrott @kayomarz It's very gratifying to hear this has been helpful for you!