vscode: Debugger: Exclude caller from breakpoint hit condition
It is now about the 20th time that I wished I had this feature, so I’m finally filing this feature request.
I think the UX around breakpoint hit conditions can be improved. Similar to log points I find breakpoint conditions not very accessible (but this might be a personal preference). Thus, I rarely use them even though they could solve some problems I encounter during debugging.
Maybe this is because I’m usually using the mouse when debugging and “programming” the right stop condition requires context switches. Or because they require too many clicks to be setup. Whenever I use breakpoint hit conditions, I feel slow.
This feature is about making breakpoint hit conditions a little bit more accessible.
The Feature
It would be really nice if I could simply exclude a caller from a breakpoint hit condition:
If a breakpoint is hit and the statement that the breakpoint is on is about to be executed, I want to be able to right-click on some stack frame and have an option “Don’t trigger breakpoint in this context”.
If I click on it, the breakpoint hit condition should be extended to return false when the selected stack frame is still on the stack.
This way, this breakpoint would never be hit when called from renderLine (because renderLine is spammy, which makes it difficult to debug the actually problematic context):
Implementation Details
This requires a small UI part (an additional context menu entry) and a larger debug adapter part (figuring out how to formalute the exclusion as valid JS condition, probably involving new Error().stack).
More Ideas
I think these contextual actions make hit conditions way easier to use.
Maybe something like this could also make sense for the watch view - “Restrict hit condition to x === 1” (or x !== 1), if x currently is 1.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 16 (16 by maintainers)
This was implemented using existing VS Code extension points and APIs (the only tweak in core was to add additional context to actions on the call stack). E.g. actions were contributed to the context menu and view and then a tree view and TreeDataProvider was implemented in js-debug.
Indeed, that should be possible given we have good enough context keys and data passed when the command is executed
In JavaScript debugging, there’s a context menu action to exclude a specific calling location from breaking at the current paused location.
The currently excluded callers are shown in a basic tree view, which allows going to and removing locations
These are only persisted in memory right now, so reloading will clear any currently-excluded locations.
I think I want to do this, but next iteration is housekeeping. Bumping to Nov.
Not happening this milestone, moving to October
I like the overall push to make Conditional Breakpoints and Hit Count breakpoints easier to use, since currently they are a bit hidden and not so easy to use as you say.
As for this particular action: we could only do it when the debug adapter supports the hitBreakpointIds since then we can correlate between a stopped event and a breakpoint. So in case the
hitBreakpointsIdsare present we could show this action.You idea to use conditions to control this would not easily work for every language, so I think we need something more general.
@weinand for ideas