Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support for long / asynchronous call stacks in Node.js debugger #7507

Closed
jokeyrhyme opened this issue Jun 9, 2016 · 1 comment
Closed

support for long / asynchronous call stacks in Node.js debugger #7507

jokeyrhyme opened this issue Jun 9, 2016 · 1 comment
Assignees
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality

Comments

@jokeyrhyme
Copy link

  • VSCode Version: code --version -> 1.3.0-insider
  • OS Version: OS X 10.11.6 Beta (15G12a)

Steps to Reproduce:

  1. start with this code

    setTimeout(() => {
      Promise.resolve()
        .then(() => {
          throw new Error('catch me!')
        })  
    })
  2. set a breakpoint on the throw, and debug in VSCode (as a Node.js project)

    screen shot 2016-06-10 at 09 19 15

    • observe that the Call Stack lists just a single frame.
  3. debug this in Chrome, with DevTools, with "Async" checked (near the Call Stack and Breakpoints lists)

    screen shot 2016-06-10 at 09 19 05

    • observe that the Call Stack lists multiple asynchronous frames

Whilst researching this, I did come across a similar feature request for node-inspector:

Being able to easily trace the asynchronous flow leading up to an exception (or a breakpoint) is an incredibly powerful tool in the JavaScript developer's arsenal.

It is interesting to note that this is not on by default in Chrome DevTools. Perhaps having this on all the time has considerable performance ramifications? I've had "Async" checked ever since it was announced, but I can imagine a release that turns this on by default could be met with developer confusion / frustration.

Would following Chrome's lead here and just providing a checkbox (or a flag in the debug configuration JSON) be the best initial approach?

@weinand
Copy link
Contributor

weinand commented Jun 13, 2016

duplicate of #5552

@weinand weinand closed this as completed Jun 13, 2016
@weinand weinand added debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality labels Jun 13, 2016
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality
Projects
None yet
Development

No branches or pull requests

2 participants