vscode-python: Support for customizing exception breakpoints in debugger
Today the debugger supports breaking into specific exceptions by listing the exceptions in the launch.json file.
Now that PTVSD supports the protocol, Its a good time to visit how these custom exception breakpoints can be passed into PTVSD, here’s are the two solutions:
Option 1: Note: We’d need to add lot more exceptions into the list,
Option 2: Go with the launch.json approach (configure exceptions in the launch.json as done today - no GUI).
here’s option 1:
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 39
- Comments: 27 (6 by maintainers)
The most useful thing is to be able to “turn off break on exception” on a specific exception that is happening too often, like “GeneratorExit” exceptions that happen in swig wrappers. So I don’t really care about the full list of all possible exceptions, rather the inverse, which is the much smaller list of exceptions that I don’t care about.
This is critical feature ask for Python given that language requires exceptions for various core features, unfortunately. Unless there is an ability to disable break on
StopIterationandGeneratorExit, integrated debugging becomes useless on more difficult bugs. Hope this gets in soon!Is there a temporary workaround would allow us to ignore exceptions from certain files? This is a big blocker for more in-depth Python development. Visual Studio itself has a good implementation of this paradigm.
This is a frequent annoyance when using werkzeug (flask) auto-reloading. The reloader throws a SystemExit exception with code == 3 to announce the reload. The vscode debugger rethrows this uncaught exception on every reload which defeats the purpose of the autoreload and forces a click for a new debugger session.
It would be great to be able to ignore SystemExit in this case (I’m assuming debugpy would then cleanly handle the rest, though I haven’t investigated that).
If you’re using justMyCode: false (which can be very useful), this also forces a useless context shift to the SystemExit location which adds more clicks and is generally annoying.
@pcolmer This was in an older version of the extension (that shipped with an older debugger) and it is no longer available in the current version. Please upvote this issue so we can track interest in this feature. @luabud /cc
Where is this documented, please?
@brettcannon I think we should follow the Mono approach, but since this is new functionality it can be added after the stable release.
Closing as we do not plan to implement this change within the Python extension.
@ygoe that starts new threads everytime you change a source file and save it, plus it doesn’t even work: it doesn’t update the actual code behind your endpoints, it’s still using the old code. But you can achieve what you (probably) want by adding the debug option
"django": truein yourlaunch.json, or alternatively you could wait until the following PR is accepted and then use"flask": true: https://github.com/microsoft/debugpy/pull/721@DonJayamanne yes, that is intentional, we’ll prioritize this after the stable release.