Repository navigation
Setting to control the default state of exception breakpoints (Uncaught Exceptions re-enabled in every new workspace/worktree) #6114
Description
Is your feature request related to a problem? Please describe.
The debug adapter declares the "Uncaught Exceptions" filter in exceptionBreakpointFilters with default: true, so every fresh workspace starts with the debugger pausing on uncaught exceptions. VS Code persists the checkbox state per workspace and offers no settings-level override, so the only way to change it is manually unchecking it in the Breakpoints view, once per workspace.
That used to be a one-time annoyance per project, but it has become a recurring one now that I work with git worktrees a lot: a short-lived worktree per task, each mounted at its own path. Every worktree is a brand-new workspace to VS Code, so "Uncaught Exceptions" comes back for every task and I have to remember to open the Breakpoints view and uncheck it again before debugging. Forgetting means the debugger stops on exceptions I did not want to break on.
Describe the solution you'd like
A user-level setting that controls the default state of the exception breakpoint filters, for example:
"dart.exceptionPauseModeDefault": "none" | "unhandled" | "all"VS Code applies the adapter-declared default flags whenever a workspace has no persisted exception breakpoint state, so having the extension/adapter declare defaults based on this setting would fix exactly the fresh-workspace case while leaving any per-workspace choices intact.
Describe alternatives you've considered
- Unchecking the filter manually in every new worktree (current workaround).
- Reusing stable worktree paths so VS Code's workspace storage carries the state over. Works, but constrains the workflow.
- A VS Code-level override for exception breakpoint defaults: none exists, the state is workspace-scoped by design, and there is even a report of the checkbox re-enabling itself (Breakpoint option "Uncaught Exceptions" is activated automatically microsoft/vscode#172354).
Additional context
Other debug adapters expose configuration for exception breaking behavior outside the per-workspace UI state, for example vscode-java-debug's user settings (java.debug.settings.exceptionBreakpoint.exceptionTypes, .skipClasses, .allowClasses) and vscode-php-debug's ignoreExceptions launch.json option.
Related: #3897 asked for the same capability from an nvim-dap perspective; this request is about the default applied in VS Code itself.
Activity
DanTup commentedon Jul 9, 2026
It feels a little odd for Dart-Code to tell the DA what to set the defaults to, which DA then just sends back to VS Code. However, I can't think of a better way to do this (besides VS Code persisting these cross-workspace, or copying stored preferences like this to worktrees, neither of which I think are likely). We do already pass some preferences (like whether to execute getters) so it's not that unique (other than the values just being passed back to the client rather than being used internally).
@bkonyi this will require some changes in DAP too - are you still working on moving that to its own package? (I don't want to cause conflicts, or potentially lose the change if you are).
bkonyi commentedon Jul 14, 2026
Yup, I'm just waiting on a review for https://dart-review.googlesource.com/c/sdk/+/520160.
DanTup commentedon Aug 6, 2026
I started looking at this, and realised that we need to provide these details prior to the
launch/attachrequests being sent (which is where we'd normally send additional data to the debug adapter), because we need to include them in theinitializeresponse.So we don't have an existing mechanism for passing defaults here, we'd have to do something different (like CLI flags), which feels a bit weird.
@jagmit so now I'm wondering, if the intention is to run without stopping, why use Debug (
F5) and not just Run (Ctrl+F5)? It's basically the same, except it automatically disables pausing.jagmit commentedon Aug 28, 2026
@DanTup Thanks for looking into it. Run (Ctrl+F5) does not cover my case: I still want a real debug session so I can drop a breakpoint on demand while the app is running and inspect state when I hit it. What I do not want is the "Uncaught Exceptions" filter being on by default, because it stops the app on exceptions I never asked to break on and I have to remember to turn it off in every fresh workspace/worktree before anything else.
So the ask is really just about the initial value of that one checkbox, not about disabling pausing altogether.
On the mechanism: since the defaults have to be in the
initializeresponse, a CLI flag on thedebug_adaptercommand (in the spirit of the existing--test, e.g.--default-exception-pause-mode=none) seems like the most straightforward route to me. It is a bit unusual, but the information is genuinely startup-only, so a startup flag feels like an honest fit. Happy to go with whatever you prefer, though.DanTup commentedon Sep 23, 2026
Thanks! Rather than a new flag, I realised we could just add a custom flag to the initialize args, similar to what we did for macro support (which was subsequently removed in dart-lang/sdk@0a15269).
This is much simpler because it's all just inside the based debug adapter/args and will apply to both Dart and Flutter without needing to make CLI changes in both.
DanTup commentedon Sep 23, 2026
Actually, since this is non-standard anyway, we could just do it all client-side by rewriting the default values in the initialize response in the middleware (instead of injecting values on the way out). That will avoid needing any SDK changes at all.