Chromium

This is a V8 issue since Error.stack is in V8, and the issue is about extending Error.stack with information about the cause.

This is a V8 issue since Error.stack is in V8, and the issue is about extending Error.stack with information about the cause.

For the record, when I filed this issue it was specifically about DevTools support. (Original title: “​Support error.cause in DevTools) That is, displaying an error’s cause when available, similar to what Firefox does when using the example in comment #1 or comment #4.

I’m not sure how we arrived at instead wanting to extend .stack, but I’d question if this is the right approach. It doesn’t match the spec nor any existing implementation.

I think we can improve tooling support without making observable changes to the platform.

One V8-level change we could consider is using cause in descriptionForError (similar to how we’re already using message if available): https://source.chromium.org/chromium/chromium/src/+/main:v8/src/inspector/value-mirror.cc;l=254-305;drc=897757e2416f74ef06d28a5611b0793e5f227f28

I think we need to have the cause printed as part of Error.stack indeed. Error.stack is the commonly used way to share call frames..

Hey

I'm probably not qualified enough to decide for you.

Just wanted to give some references to how Node.js implemented it as a dev tool feature in Node 16.14: https://github.com/nodejs/node/issues/38725

PR:

• https://github.com/nodejs/node/pull/41002
• https://github.com/nodejs/node/pull/41002

The tool they use to log errors to the console: require("node:utils").inspect(error)

By default it does not log the "whole causal chain" You'd have to explicitly use their API and increase the maximum depth for that: inspect(error, {depth: Infinity}). To be honest, this was kind of surprising to me, and I've been bitten by this behavior while trying to use deeply nested error causes inside AggregateError: https://github.com/nodejs/help/issues/4337

And it seems the info is not attached to the stack attribute and logging the stack does not print the full causal chain either.

> new Error("boom",{cause: new Error("child")})
Error: boom
    at REPL3:1:1
    at ContextifyScript.runInThisContext (node:vm:121:12)
    ... 7 lines matching cause stack trace ...
    at [_line] [as _line] (node:internal/readline/interface:887:18) {
  [cause]: Error: child
      at REPL3:1:26
      at ContextifyScript.runInThisContext (node:vm:121:12)
      at REPLServer.defaultEval (node:repl:599:22)
      at bound (node:domain:432:15)
      at REPLServer.runBound [as eval] (node:domain:443:12)
      at REPLServer.onLine (node:repl:929:10)
      at REPLServer.emit (node:events:530:35)
      at REPLServer.emit (node:domain:488:12)
      at [_onLine] [as _onLine] (node:internal/readline/interface:416:12)
      at [_line] [as _line] (node:internal/readline/interface:887:18)
}

> new Error("boom",{cause: new Error("child")}).stack
'Error: boom\n' +
  '    at REPL9:1:1\n' +
  '    at ContextifyScript.runInThisContext (node:vm:121:12)\n' +
  '    at REPLServer.defaultEval (node:repl:599:22)\n' +
  '    at bound (node:domain:432:15)\n' +
  '    at REPLServer.runBound [as eval] (node:domain:443:12)\n' +
  '    at REPLServer.onLine (node:repl:929:10)\n' +
  '    at REPLServer.emit (node:events:530:35)\n' +
  '    at REPLServer.emit (node:domain:488:12)\n' +
  '    at [_onLine] [as _onLine] (node:internal/readline/interface:416:12)\n' +
  '    at [_line] [as _line] (node:internal/readline/interface:887:18)'

Firefox Nightly shows a similar behavior and does not log the causal chain when logging the parent error.

To me, each error has a different stack trace, so it kind of makes sense to keep them isolated from each other.

However, the most common case is that the parent/child errors would share many stack frames, so the dev tool should rather be able to deduplicate stackframes them to avoid printing them multiple times. (cf how Node.js does it in my example above)

If logging the stack now prints the causal chain too, how could anyone get the "raw" stacktrace anymore, in case they don't want to see/log/report the whole stacktrace but only focus on the stackframes that are related to the current Error? (and not its cause).

That looks to me like a risky change too, some tools might read the stack and now have trouble parsing it.

Another example is how Java does it using nested exceptions:

Exception e = new RuntimeException("Parent error",
  new RuntimeException("Child error")
);
      
      
System.out.println("getStackTrace : " + java.util.Arrays.toString(e.getStackTrace()));
      
e.printStackTrace();

getStackTrace : [MyClass.main(MyClass.java:3)]

java.lang.RuntimeException: Parent error
	at MyClass.main(MyClass.java:3)
Caused by: java.lang.RuntimeException: Child error
	... 1 more

It's possible to get stack frames without the causal chain. However printStackTrace() will print the causal chain.

I agree it seems nice to just include the cause in stack — but it’s a change that would risk web compat issues, require standardization work, and TC39 stakeholder buy-in before we can proceed. Whoever wants to pursue that has my support.

To help users in the mean time, we could solve it at the V8 Inspector / DevTools level instead, without any platform-observable changes. This matches what Firefox Developer Tools and Node.js do: they helpfully print the cause whenever an error instance is logged, but avoid messing with .stack.

Thanks for the idea. That Node.js approach looks interesting.

After offline discussion with Mathias, I'm convinced that while it would certainly be useful to include the cause in Error.stack, the risk of breaking all kinds of assumptions about the shape of Error.stack produced by V8 is extremely high. So I'm leaning towards the safe option of a DevTools front-end only solution for now.

Is Error.stack guaranteed not to be updated to include the causal chain? We have some logging infrastructure that currently calls Error.stack to get the stack trace, and I'm planning to update it to traverse the causal chain and concatenate the stack traces. If Error.stack were to be updated to include the causal chain, then it would break the logic that I'm planning to implement.

would be really nice to see this implemented as our application strictly follows wrapping errors with the cause property. The only way for us to view the cause chain currently is with firefox.

It would be nice to log the entire cause chain in the log however, and not just withing the stack property.

Some log like:

console.error(
  new Error("cannot add user", {
    cause: new Error("call to /users failed with a 500 status", {
      cause: new Error("database call to users table failed")
    })
  }),
);

should log something like:

Error: cannot add user
    at...
  [cause]: Error: call to /users failed with a 500 status
      at...
    [cause]: Error: database call to users table failed
        at...

as it would generate fairly large logs, maybe the cause blocks would be dropdowns.