-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Breakpointing with python unittest #550
Comments
To clarify - did you try locally patching your debugpy to enable user-unhandled exceptions, but it still didn't work as expected when you enabled the corresponding filter in UI? |
Sorry that wasn't clear. I followed the advice given in the linked comment, but found that my settings already matched the suggested changes: {"filter": "userUnhandled", "label": "User Uncaught Exceptions", "default": True}, |
The code in question was changed slightly since that comment was written: it's now conditional on environment variable If you have enabled it successfully, the exception filter should show up "User Uncaught" in addition to "Uncaught" and "Raised". Are you seeing it? |
As in, in my export DEBUGPY_EXCEPTION_FILTER_USER_UNHANDLED=1 and then restart VSCode? |
That should work, although I'd check it manually in the terminal first (i.e. export in some shell, then launch VSCode from that same shell). |
I've tried a few combinations including:
Unfortunately none give me the extra breakpoint button. Any further ideas? |
I even hardcoded exception_breakpoint_filters = [
{"filter": "raised", "label": "Raised Exceptions", "default": False},
{"filter": "uncaught", "label": "Uncaught Exceptions", "default": True},
]
exception_breakpoint_filters += [
{
"filter": "userUnhandled",
"label": "User Uncaught Exceptions",
"default": True,
},
]
# if int(os.getenv("DEBUGPY_EXCEPTION_FILTER_USER_UNHANDLED", "0")) != 0: But this still didn't add the button. |
It seemed to work for me (maybe you're editing a As a note, after changing the environment variable, you need to run it once for the button to appear (as the VSCode UI will be updated based on what the debugger gives at runtime). i.e.: it should show: After that, you need to enable it. If you still can't get it to work, please provide the logging (maybe it can give some hint on what's not correct). i.e.:
|
The trick I was missing was to run it once to get it to refresh! Thanks! |
Great that it's working now ;) |
Environment data
python.languageServer
setting: PylanceExpected behaviour
I am running some tests using python's unittest. When an exception is raised, I'd like VS Code to breakpoint at the point the error is thrown. I have "Uncaught Exceptions" enabled and "Raised Exceptions" disabled, and I see the desired behaviour when running the code normally (not with unittest). In the minimum working example below, I'd like the code to breakpoint at line 4 when the exception is raised.
Actual behaviour
Instead of the desried/expected behaviour, the breakpoint is on the final line with an empty stack call and no way of getting back to line 4 or the variables present at that time. This makes debugging useless. I imagine this occurs because unittest catches all uncaught exceptions, so I'd like a way for VSCode to breakpoint if the
except
was not written by the user (as is the case with unittest). I've seen a suggested solution here (microsoft/vscode-python#14056 (comment)) and also thought that settingjustMyCode
might help, too, but neither did.Caveat 1: I know I could enable "Raised Exceptions" but the code I'm working on has lots of intentional raises which are caught. So enabling "Raised Exceptions" would take too long to sift through all the intentional raises.
Caveat 2: I know there is the "Test" tab. When I click to debug the test it says "No Tests Ran". This is strange because I simply run the test from inside the "Test" tab, it successfully runs (it still raises the error, and there is no breakpointing, but it runs at least).
Steps to reproduce:
In the example below, I'd like the breakpoint at line 4 (
raise RuntimeError()
), but I'm getting it instead at line 11 (unittest.main()
), which has an empty stack call and no way to get back to line 4 or any of the variables that were present at that time.The text was updated successfully, but these errors were encountered: