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

Break on conditional exceptions in node debugger #104453

Closed
cdaringe opened this issue Aug 11, 2020 · 8 comments
Closed

Break on conditional exceptions in node debugger #104453

cdaringe opened this issue Aug 11, 2020 · 8 comments
Assignees
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality on-testplan
Milestone

Comments

@cdaringe
Copy link

ref 1

Problem

It is often challenging to narrow the emitter of an exception using node + vscode tooling. For example, many node internals throw exceptions often, as do userland libraries. skipFiles is a noble attempt that helps to aide with this problem, but requires that the user collect possibly large domains of possible paths up front, where often it is unknown whom is responsible for emitting an exception. As suggested in similar threads, I cannot reasonably use <node_internals> in my skipFiles, as code that is-on-the-fly compiled is put into VM scripts, and is thus ignored. Further, in some cases, i'm OK breaking inside of internals. During daily debugging, I have knowledge about an exception (perhaps stderr output from a prior run), that I really want to hone in on--and thus want a conditional breakpoint to rapidly narrow my search.

This feature would add a mechanism like conditional breakpoints, but just to exceptions. Perhaps it would be as follows:

  • select [x] All exceptions in the debugger
  • right click => add condition
  • observe placeholder prompt "err =>
  • user fills in function
  • user hits enter to save the function
err => err && err.message.match(/react/)

the need for a lamba here is because the exception of course isn't otherwise in scope--providing a function lets us introspect the error.

@connor4312
Copy link
Member

I've decided this is best implemented as a formal DAP feature and opened a proposal there: microsoft/debug-adapter-protocol#137 Moving this issue to backlog until that's resolved. (September release at the soonest, as our iteration ends on Monday)

@connor4312 connor4312 modified the milestones: August 2020, Backlog Aug 28, 2020
@rrmistry
Copy link

@connor4312 , would conditional breakpoints be a separate DAP feature request?

I tried but couldn't find an existing issue (open / closed) for this exact feature request.

@connor4312
Copy link
Member

Conditional breakpoints are already supported in DAP and in VS Code https://code.visualstudio.com/docs/editor/debugging#_conditional-breakpoints

@rrmistry
Copy link

Never mind. I found it. For anyone else on the same path, the way to set conditional breakpoints is right click the breakpoint and select Edit Breakpoint:
image

@connor4312
Copy link
Member

This is implemented in VS Code in #111227, which debuggers will need to adopt to enable; I'll use this feature request to track adding to the JS debugger.

@connor4312 connor4312 added the debug Debug viewlet, configurations, breakpoints, adapter issues label Jan 4, 2021
@connor4312
Copy link
Member

connor4312 commented Jan 4, 2021

This will be in the next nightly build. The current exception is in the error variable, for example:

recording (7)

@cdaringe
Copy link
Author

cdaringe commented Jan 4, 2021

I am thrilled! I'll be installing nightly immediately to try this out. @weinand and @connor4312, deep gratitude for this killer feature

@connor4312 connor4312 added the verification-needed Verification of issue is requested label Jan 26, 2021
@isidorn isidorn added on-testplan and removed verification-needed Verification of issue is requested labels Jan 26, 2021
@isidorn
Copy link
Contributor

isidorn commented Jan 26, 2021

@connor4312 adding the on-testplan since this should be covered by a test plan item, thus no further verification should be needed if I am nto mistaken.

@github-actions github-actions bot locked and limited conversation to collaborators Feb 18, 2021
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 on-testplan
Projects
None yet
Development

No branches or pull requests

4 participants