Causes observable changes with prepareStackTrace

[o-]

When requiring the stack properties value to be eagerly evaluated in captureStackTrace there is a problematic interaction with the existing accompanying prepareStackTrace. That one allows arbitrarily formatting of the stack trace attached to the error object. This makes it observable when the string content of the stack property is computed.

The proposal here would require eager evaluation of the stack formatting code at captureStackTrace time. Whereas the current implementation does it lazily.

Error.prepareStackTrace = (error, stack) => {console.log("2. prepare")};
let err = {}; 
Error.captureStackTrace(err);
console.log("1. capture");
err.stack;

Here we would essentially have to swap the order of effect 1 and 2.

I think this is not just a theoretical issue. Next to an observable change in behavior it would also make the prepareStackTrace API prohibitively expensive to use.

There is evidence of effectfull and expensive prepareStackTrace handlers, see e.g., source-map-support for node.

[mgaudet]

See #1.

I'm not intrinsically opposed to an accessor property; not terribly excited by it and we need to make sure we don't violate invariants others want too.l

[ljharb]

stack itself is already an accessor in https://github.com/tc39/proposal-error-stack-accessor; i'm not sure why it'd be anything else in the standard?

[mhofman]

@ljharb when using the setter in that proposal, it defines an own string prop. I think that matches what captureStackTrace does in my mind: capture information about the current stack at the call site, and set as an own prop on the target object.

[mhofman]

it would also make the prepareStackTrace API prohibitively expensive to use.

prepareStackTrace is non-standard, and definitely cannot be standardized as-is. It would be unfortunate to dramatically complicate this proposal for it.

Also it would only become expensive for calls to captureStackTrace that do not result in an access to the stack. Does Google have any data on how often prepareStackTrace triggers based on Error instance stack access vs how often captureStackTrace is called? Even better would be to know how often the stack accessor installed by captureStackTrace is called.

[o-]

prepareStackTrace is non-standard, and definitely cannot be standardized as-is. It would be unfortunate to dramatically complicate this proposal for it.

That I understand. But the problem remains that we would create a new potential web compatibility issue by trying to solve one.

Also it would only become expensive for calls to captureStackTrace that do not result in an access to the stack.

I would assume that if you e.g., use the stack property for logging and reporting uncaught exceptions that this would be 99.9% of all your throws in the application.

Does Google have any data on how often prepareStackTrace triggers based on Error instance stack access vs how often captureStackTrace is called? Even better would be to know how often the stack accessor installed by captureStackTrace is called.

I don't think we have. This would indeed be interesting to know before we decide to change it to eagerly evaluate.

[mhofman]

Also it would only become expensive for calls to captureStackTrace that do not result in an access to the stack.

I would assume that if you e.g., use the stack property for logging and reporting uncaught exceptions that this would be 99.9% of all your throws in the application.

While I could imagine most throws get their stack accessed (I'm doubtful it's 99.9% though), I can't imagine that objects with a stack created by captureStackTrace are thrown that often compared to error instances.

I'm just trying to understand how much of a performance problem eager stack construction for captureStackTrace really is.

[o-]

After a bit of archaeology I found out that we actually had all the variations in the past. There is some back-story in https://issues.chromium.org/issues/42209272

It seems we made it lazy due to external bug reports for performance. And then we turned it into a JS accessor to not have a data property causing effects on read.

[o-]

While I could imagine most throws get their stack accessed (I'm doubtful it's 99.9% though), [...]

Sorry that was a bit unclear. I meant the opposite. I was thinking of an application where uncaught exceptions are logged to find bugs in the application. Assuming that most exceptions are actually correctly caught, this would mean that almost none of the stack properties are accessed.

[mhofman]

After a bit of archaeology I found out that we actually had all the variations in the past. There is some back-story in https://issues.chromium.org/issues/42209272

That is extremely valuable feedback. Also sounds like instrumenting Chrome wouldn't help catch these use cases.