You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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:
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.
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.
Activity
ajvincent commentedon Apr 7, 2018
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 commentedon Apr 9, 2018
node.js tries decorates stack traces to look a bit like:
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
sourceLineis the line of code on which the exception occured; in this exampleconsole.log('hi)theScottyJam commentedon May 25, 2021
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 commentedon Oct 26, 2021
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.