Support for customizing exception breakpoints in debugger

Mikhail Arkhipov (@MikhailArkhipov)

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:

Mikhail Arkhipov (@MikhailArkhipov) Brett Cannon (@brettcannon) Dan Taylor (@qubitron) cc

Don Jayamanne (@DonJayamanne)

Don Jayamanne (@DonJayamanne) I think listing all possible exceptions types will be overloading the UI too much, and not clear how it would work for user defined exception types. Ideally you could add exceptions to this list, similar to how the add function breakpoint works, though I assume this would require upstream work from VS Code to support. I'm thinking the "+" button would show a menu allowing you to choose between "Add Function Breakpoint" and "Add Exception Breakpoint". Upon selecting "Add Exception Breakpoint" you could then type in the exception name you wanted.

If we can't do the above, then I'd stick with launch.json. To improve discoverability we could add a checkbox in the list above that turns break on specific exceptions on/off, named something like "Exceptions Specified in launch.json". This would also allow you to turn off the exception breakpoints mid-debug session if they are hitting too often & getting in your way.

Here's how its configured in the Mono debugger (from Msft):

They are configured per workspace, not per debug configuration
Settings stored in settings.json instead of launch.json
Settings can be managed via gui (see below)

Yes that sounds like a different issue to open.

Just a guess here: I wonder if this is due to how just-my-code is defined, I believe uncaught exception means "not caught by your code". If the test framework is somehow considered your code then the debugger might consider that a handled exception. Or maybe a different issue altogether.

Dan Taylor (@qubitron)

Dan Taylor (@qubitron) Good thinking, but I don't think that's the case since it handles all other just-my-code procedures correctly (i.e. when I click the step-into button for a function call, it will not do that unless it's my code).

Edit: On second thought... I'm unsure of how the debugger is invoked via pytest, so I'm not so sure. I wouldn't dismiss the idea too quickly.

I have created a new issue #14056 with full details.

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.

I'm new to VS Code and Python but this is also annoying to me. I cobbled this together, it seems to work, but might be really bad style:

if __name__ == "__main__":
	while True:
		try:
			app.run(debug=True, host="0.0.0.0", port=8000)
			break
		except KeyboardInterrupt:
			print("Web server stopped")
			break
		except SystemExit as err:
			if err.code == 3:
				# It's VS Code trying to reload the app, a bit clumsy. Help it out.
				continue
			break

Yves Goergen (@ygoe)

Yves Goergen (@ygoe), it seems like that should be posted as a new issue or question on stackoverflow.

Maybe. Actually I'm more interested in this bug fixed properly than my workaround to be good. It even seems like it's not effective because after such a reload no breakpoints work anymore, they're just skipped. So it's probably better if everything falls apart than trying to keep it alive in this state.

Yves Goergen (@ygoe)

Yves Goergen (@ygoe), what I'm saying is your post doesn't seem related to this issue thread which is titled "Support for customizing exception breakpoints in debugger". Perhaps you need to start a new thread on better support for Flask app or something, if that's what you are using.

Yves Goergen (@ygoe)

Yves Goergen (@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": true in your launch.json, or alternatively you could wait until the following PR is accepted and then use "flask": true: microsoft/debugpy#721

Closing as we do not plan to implement this change within the Python extension.

is there an alternate plan so solve this general python debugging problem?

Navigation Menu

Repository navigation

Support for customizing exception breakpoints in debugger #850

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for customizing exception breakpoints in debugger #850

Description

Activity

qubitron commented on Feb 21, 2018

DonJayamanne commented on Mar 5, 2018

22 remaining items

qubitron commented on Sep 23, 2020

ChadBailey commented on Sep 23, 2020

sbuser commented on May 8, 2021

ygoe commented on Sep 2, 2021

lovettchris commented on Sep 2, 2021

ygoe commented on Sep 2, 2021

lovettchris commented on Sep 3, 2021

Daniel-DI commented on Sep 9, 2021

cwebster-99 commented on Jan 12, 2023

lovettchris commented on Jan 12, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions