search

tc39 / proposal-error-stacks

ECMAScript Proposal, specs, and reference implementation for Error.prototype.stack / System.getStack
https://tc39.github.io/proposal-error-stacks/
MIT License
168 stars 13 forks source link

A standard way to extend stack traces #45

Closed Silic0nS0ldier closed 2 years ago

Silic0nS0ldier commented 2 years ago

There are occasions where stack traces fail to pinpoint the error source (e.g. Error being constructed on a unique code path, rethrowing of Error instances). It would be useful if a standard way to augment a stack trace with additional context was available.

A standard here may aid error monitoring tools (e.g. Sentry) which attempt to parse the stack trace to provide a richer debug experience.

Scenarios

Error being constructed on a unique code path

trace-unhandled can be used to address this issue during development (it is stated as not being for production use). It produces stack traces similar to the following.

(node:1234) UnhandledPromiseRejectionWarning
[ Stacktrace altered by https://github.com/grantila/trace-unhandled ]
Error: foo
    ==== Promise at: ==================
    at Promise.then (<anonymous>)
    at Object.<anonymous> (/my/directory/test.js:9:5) 

    ==== Error at: ====================
    at Object.<anonymous> (/my/directory/test.js:1:13)

    ==== Shared trace: ================
    at Module._compile (internal/modules/cjs/loader.js:776:30)
    ... more lines below ...

The stack trace differs considerably from the normal stack.

(node:1234) UnhandledPromiseRejectionWarning: Error: foo
    at Object.<anonymous> (/my/directory/test.js:1:13)
    at Module._compile (internal/modules/cjs/loader.js:776:30)
    ... more lines below ...

Rethrowing of Error instances

No sample necessary for this scenario. The stack trace will simply not include the rethrow site. There is some overlap with #41 here, perhaps mainly with how the trace should be extended.

ljharb commented 2 years ago

I'm not really sure what you mean by a standard way to extend stack traces. Error objects already can have an AggregateError, where you can provide anything you like in the errors array.

Either way, this is beyond the scope of this proposal - this proposal's sole and entire goal is to specify the current behavior of browsers, while providing robust static methods to access this data. This kind of idea would need to wait for a follow-on proposal, after this one has advanced.