No breakpoint for Uncaught Exceptions while debugging tests

UPDATE: Seems this is an enhancement that may be “coming soon”. If you’ve found this bug report in hopes of a fix, and are willing to accept the risks look at this reply for instructions on manually enabling the functionality

Searched for duplicates, none found. See the following post/thread for back story: https://github.com/microsoft/vscode-python/issues/850#issuecomment-696992737

Environment data

Version: 1.49.0
Commit: e790b931385d72cf5669fcefc51cdf65990efa5d
Date: 2020-09-10T17:39:53.251Z (1 wk ago)
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 18.7.0

• Extension version (available under the Extensions sidebar): v2020.8.109390
• OS and version: macOS Mojave 10.14.6 (bug happens on every OS I’ve tried - Linux Mint & Windows 10)
• Python version (& distribution if applicable, e.g. Anaconda): 3.8.1 (64 bit) - appears unrelated
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): N/A
• Relevant/affected Python packages and their versions: pytest-5.4.3
• Relevant/affected Python-related VS Code extensions and their versions: N/A
• Value of the python.languageServer setting: Microsoft Python Language Server version 0.5.51.0

[Info  - 9:39:50 AM] Analysis cache path: /Users/####/Library/Caches/Microsoft/Python Language Server
[Info  - 9:39:50 AM] Microsoft Python Language Server version 0.5.51.0
[Info  - 9:39:50 AM] Workspace root: /Users/####/Documents/Code/####
[Info  - 9:39:51 AM] GetCurrentSearchPaths /usr/local/opt/python@3.8/bin/python3 
[Info  - 9:39:51 AM] Interpreter search paths:
[Info  - 9:39:51 AM]     /usr/local/Cellar/python@3.8/3.8.1/Frameworks/Python.framework/Versions/3.8/lib/python3.8
[Info  - 9:39:51 AM]     /usr/local/Cellar/python@3.8/3.8.1/Frameworks/Python.framework/Versions/3.8/lib/python3.8/lib-dynload
[Info  - 9:39:51 AM]     /Users/####/Library/Python/3.8/lib/python/site-packages
[Info  - 9:39:51 AM]     /usr/local/lib/python3.8/site-packages
[Info  - 9:39:51 AM] User search paths:
[Info  - 9:39:55 AM] Initializing for /usr/local/opt/python@3.8/bin/python3
[Info  - 9:39:55 AM] Analysis caching mode: None.

Expected behaviour

When debugging a unit test with the breakpoint of Uncaught Exceptions enabled, the debugger should break on the exception rather than finishing the test as a failure. This is the behavior when invoking the debugger via the typical way through Run -> Start Debugging.

Actual behaviour

When debugging a unit test with the breakpoint of Uncaught Exceptions enabled, the debugger does not break on the exception and finishes as a failed test.

Steps to reproduce:

1. Create new folder with the following files:

main.py

def main():
    raise Exception("Demo")


if __name__ == "__main__":
    main()

test_main.py

from main import main


def test_main():
    main()

1. Begin debugging (F5) main.py with standard debug options
2. Observe that debugger breaks on exception, allowing you to use the interactive debugging console

-> main
 > <function main at 0x108dbd940>

1. Install pytest & discover tests (may need to add "python.testing.pytestEnabled": true to settings.json)
2. Click Debug Test over test_main in test_main.py
3. Observe that the debugger does not break and instead the test results come back as a failure

============================= test session starts ==============================
platform darwin -- Python 3.8.1, pytest-5.4.3, py-1.8.1, pluggy-0.13.1
rootdir: /Users/####/Documents/Code/test_demo
collected 1 item

test_main.py F                                                           [100%]

=================================== FAILURES ===================================
__________________________________ test_main ___________________________________

    def test_main():
>       main()

test_main.py:5: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

    def main():
>       raise Exception("Demo")
E       Exception: Demo

main.py:2: Exception
- generated xml file: /var/folders/lz/hcbk8xvj2gdf9htx6r3w6cmrgy1jf9/T/tmp-79341Yr1at8rMslzO.xml -
=========================== short test summary info ============================
FAILED test_main.py::test_main - Exception: Demo
============================== 1 failed in 0.15s ===============================

Logs

Intentionally left out, due to difficulty parsing out private data. See logs above

[ChadBailey]

You can edit your local copy of debugpy (bundled with the extension, wherever it’s installed) to try it out already. Just uncomment this line:

https://github.com/microsoft/debugpy/blob/cf65911a7acbc7ae8d4edd47d00e84cf27fadada/src/debugpy/adapter/clients.py#L165

Woohoo!! I got it working!

Here’s some steps for posterity:

1. Open VSCode and visit console Ctrl+`

2. Click the OUTPUT tab, select Python from the dropdown

3. Hit Ctrl+F and search for pythonFiles (Note: You may need to issue a command such as discover tests first)

4. Copy discovered system path to pythonFiles (i.e. ~/.vscode/extensions/ms-python.python-2020.9.111407/pythonFiles/) then open this folder using VSCode

5. Search all files Ctrl+Shift+F for the term userUnhandled

6. Select the search result found in clients.py and modify line to be the following

              {"filter": "userUnhandled", "label": "User Uncaught Exceptions", "default": True},

NOTE: I think I originally had a syntax error causing this, but it did not work until I toggled default to True

1. Save file and restart VSCode

[int19h]

We can’t change the meaning of “uncaught” to mean “user-uncaught”, because it’s a standard exception filter, and its current behavior is required for VS to behave as it should. So this has to be another, distinct filter (which can still be enabled by default). VS, which already supports this, hides that fact by picking one or the other category depending on Just My Code setting. But in VSCode, the filters that are advertised by the debug adapter are exposed directly by debugging UI - the extension doesn’t control that part. So, the challenge is to add that third filter in a way that makes the distinction between the two sufficiently clear.

You can edit your local copy of debugpy (bundled with the extension, wherever it’s installed) to try it out already. Just uncomment this line:

https://github.com/microsoft/debugpy/blob/cf65911a7acbc7ae8d4edd47d00e84cf27fadada/src/debugpy/adapter/clients.py#L165

This will make the filter show up. However, note that its usability is hampered by https://github.com/microsoft/debugpy/issues/399 at the moment.