Usecases

[mariusGundersen]

This issue is created for discussion

What are the usecases for this proposal? I think what we want to add is a machine readable stack trace (in addition to the human readable stack trace we have today, which is just a string). So, in what scenarios will a machine read this stack trace? I think this is important to discuss so we can design it based on some actual usecases, and so that we can know that it solves the problems people have.

To get started I can think of a few scenarios that we can consider. I'm not saying we must support these, but it's good to have discussion we can point to when we decide not to support these use cases.

• Browser/server devtools can have a standardized hook for getting stack trace
• Logging errors back to server in production
• REPL/editor (jsbin, babel, etc) presenting syntax/early/runtime errors
• Non-production libraries can catch error and present better help to devs

[ajvincent]

I have a use case: membranes.

As a comparison, I look to Mozilla Firefox: when an exception is thrown from privileged code and JS code catches the exception, the JS-to-C++ layer (XPConnect) obscures the native stack frames, replacing them with "[native code]". (At least, it used to, as I haven't checked in quite a while.)

In a JavaScript-based whitelisting membrane such as mine, an exception thrown in one object graph could leak information about the stack to the calling object graph, which it may not want to do.

If the stack trace follows a standardized format, and is rewritable, I can at least try to modify the stack trace to do a similar hiding of "private" stack frames.

[devsnek]

node.js tries decorates stack traces to look a bit like:

hello_world.js:1
console.log('hi)
            ^^^^

SyntaxError: Invalid or unexpected token

at the moment we do this with some nasty v8 hackery, it would be nice if the spec provided a way for things to hook into stack generation like v8's Error.prepareStackTrace. one signature for this method might look like:

(error, frames, { specifier, lineNumber, startColumn, endColumn, sourceLine })

where sourceLine is the line of code on which the exception occured; in this example console.log('hi)

[theScottyJam]

Not sure if examples are still wanted, but this issue is still open, so I suppose so.

Here's one I recently ran into:

I was using a finalization registry to report errors to developers when they forgot to properly handle some special objects. In its implementation, I would capture the stack trace at the time this special object was created, so that I could report this stack trace to the developer if the object was cleaned up without being handled properly.

[conartist6]

Node also demonstrates a major use case: A predictable way to trim frames from the bottom of the stack. This is useful when designing error factories. The problem with creating error factories or any shared code to handle errors is that a number of frames related to creation of the error itself end up on the stack, making it more difficult to see where the line is that really entered the error pathway.