How does this interact with Error causes?

[voxpelli]

Considering that error causes are now part of the JS standard, using that instead would be beneficial, no?

This is the approach eg I took with https://github.com/voxpelli/pony-cause

[staltz]

Wow, I had no idea about this new ES feature! Thanks! I'll consider what to do now.

[voxpelli]

@staltz Feel free to pick my brain as much as you want, here or on Discord 👍

[staltz]

Oh @voxpelli it seems like pony-cause doesn't cover a use case that's quite important for us: when an error doesn't have a .stack. Even if stackless errors shouldn't occur, they often happen in our software which is peer-to-peer (thus updating to newer libraries takes many years).

See:

console.log(
  stackWithCauses(
    new ErrorWithCause('bar', {cause: {name: 'TypeError', message: 'foo'}}),
  ),
);

ErrorWithCause: bar
    at Object.<anonymous> (/home/staltz/oss/playground/example.js:3:5)
    at Module._compile (internal/modules/cjs/loader.js:1015:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1035:10)
    at Module.load (internal/modules/cjs/loader.js:879:32)
    at Function.Module._load (internal/modules/cjs/loader.js:724:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
    at internal/main/run_main_module.js:17:47

while

console.log(clarify('foo', 'bar'));

Error: bar
    at Object.<anonymous> (/home/staltz/oss/playground/example.js:1:13)
    at Module._compile (internal/modules/cjs/loader.js:1015:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1035:10)
    at Module.load (internal/modules/cjs/loader.js:879:32)
    at Function.Module._load (internal/modules/cjs/loader.js:724:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
    at internal/main/run_main_module.js:17:47
  Error: foo

[voxpelli]

@staltz Good input! I have made an issue about adding that to stackWithCauses() 👍 voxpelli/pony-cause#22

[staltz]

Thanks! And what about the case console.log(new ErrorWithCause(......))?

[voxpelli]

@staltz ErrorWithCause is meant to be a drop in replacement for the standardised new Error('foo', { cause: err }), to be used in contexts where the built in one isn't supported (older browsers and Node 14 and older I believe).

The standard proposal doesn't specify anything around how console.log() should handle it: https://github.com/tc39/proposal-error-cause

Though Firefox prints it like this:

And Node.js 16.14.0 and 17.3.0 shipped nodejs/node#41002, making it also printing the causes

[voxpelli]

Here's a screenshot of how Node 16.14.0 console.log handles it:

[voxpelli]

Eg. pino has got support merged as well: pinojs/pino-std-serializers#78

[staltz]

Good to know! Note to self, here's how Node.js 16.14.0 renders "string errors" and stackless errors:

> console.log(new Error('bar', {cause: 'foo'}))
Error: bar
    at REPL10:1:13
    at Script.runInThisContext (node:vm:129:12)
    at REPLServer.defaultEval (node:repl:564:29)
    at bound (node:domain:421:15)
    at REPLServer.runBound [as eval] (node:domain:432:12)
    at REPLServer.onLine (node:repl:891:10)
    at REPLServer.emit (node:events:532:35)
    at REPLServer.emit (node:domain:475:12)
    at REPLServer.Interface._onLine (node:readline:487:10)
    at REPLServer.Interface._line (node:readline:864:8) {
  [cause]: 'foo'
}

> console.log(new Error('bar', {cause: {name:'TypeError',message:'foo'}}))
Error: bar
    at REPL11:1:13
    at Script.runInThisContext (node:vm:129:12)
    at REPLServer.defaultEval (node:repl:564:29)
    at bound (node:domain:421:15)
    at REPLServer.runBound [as eval] (node:domain:432:12)
    at REPLServer.onLine (node:repl:891:10)
    at REPLServer.emit (node:events:532:35)
    at REPLServer.emit (node:domain:475:12)
    at REPLServer.Interface._onLine (node:readline:487:10)
    at REPLServer.Interface._line (node:readline:864:8) {
  [cause]: { name: 'TypeError', message: 'foo' }
}

My use case is most important in Node.js, so would it be okay to ask that pony-cause follow the Node.js style of rendering in the cases of string errors and stackless errors?

[voxpelli]

@staltz That sounds like a good approach to it, I’ll try to make it happen soon 👍

[voxpelli]

@staltz What's your thoughts on this solution? voxpelli/pony-cause#23