-
Notifications
You must be signed in to change notification settings - Fork 137
FAQ
If we see issues come up often that are just usage issues, we will add them here.
A handled exception is causing the debugger to break execution, or, an exception is not causing the debugger to break execution
Look in the Breakpoints section of the Debug pane and make sure the appropriate checkboxes are checked for the behavior you want:
-
Raised Exceptions: Triggers whenever any exception is raised or reraised (if
"justMyCode":true
-- which is the default -- only triggers when an exception is raised or reraised in user code). -
Uncaught Exceptions: Triggers only when an exception would get to the entry point method of a thread (so, only if an exception would make a thread exit).
-
User Uncaught Exceptions: Triggers when a raised/reraised exception would cross the barrier from user code to library code (so, when an exception is raised or reraised it checks whether the caller is library code and the current method is in user code, if it is, then the exception is shown -- in general it's helpful if a user wants to see exceptions which are being raised in a test case and would end up being caught inside the test framework -- it can be helpful to uncover bugs in other situations too, but it may be hard to use if in your usage you do get such exceptions regularly as a part of a framework you're using).
All modes are kind of independent (so, enabling one shouldn't change the behavior of the other, although raised exceptions
with "justMyCode":false
is kind of a superset of the others).
The ability to visualize dictionaries and data frames from the debugger's local variable window and debug console is pretty limited. We recommend that you try to open the data in the data viewer. For example, you can expand your dictionary in the variable window (under the debug view), then right click on "name2" and select "View Value in Data Viewer":
This way you can better inspect your data frames.
Check your ptrace_scope
setting; it could be the problem.
See https://github.com/microsoft/debugpy/issues/743#issuecomment-937743937
For attach configurations, "subProcess" in launch.json is not applicable in any attach scenario, because by the time the debuggee sees the config, it is already too late to apply the necessary changes to the process. Instead you need to use either the API - debugpy.configure(subProcess=...)
- or the CLI - debugpy --configure-subProcess ...
- to change it.