Skip to content

Usecases #20

Open
Open

Description

@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

Activity

  1. ajvincent commented on Apr 7, 2018

    @ajvincent
    Collaborator

    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.

  2. devsnek commented on Apr 9, 2018

    @devsnek
    Member

    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)

  3. theScottyJam commented on May 25, 2021

    @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.

  4. conartist6 commented on Oct 26, 2021

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions