Python debugger breaks on caught exception within a decorator and context manager

[damien135]

Type: Bug

Behaviour

Expected vs. Actual

Expected behavior: If breakpoints are enabled only for Unchaught Exceptions and User Uncaught Exceptions, the debugger should not break in the code sample below.

Actual behavior: The debugger breaks on line 19.

Steps to reproduce:

1. Open VS code
2. Run the code sample below (integrated terminal):

from contextlib import contextmanager
from functools import wraps
def some_decorator(parameter):
    def generic_wrapper(func):
        @wraps(func)
        def wrapper(self, *args, **kwargs):
            with self.some_context_manager(parameter):
                return func(self, *args, **kwargs)
        return wrapper
    return generic_wrapper

class ExampleClass:
    @some_decorator('some value')
    def get_property_value(self):
        return {}

    @contextmanager
    def some_context_manager(self, parameter):
        raise Exception("User uncaught exception!")

example = ExampleClass()
try:
    test = example.get_property_value()
except Exception as ex:
    print("Exception successfully caught!")

Diagnostic data

• Python version (& distribution if applicable, e.g. Anaconda): 3.10.6
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Global
• Value of the python.languageServer setting: Default

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

Exception has occurred: Exception       (note: full exception trace is shown but execution is paused at: some_context_manager)
User uncaught exception!
  File "...\TestException.py", line 19, in some_context_manager (Current frame)
    raise Exception("User uncaught exception!")
  File "...\TestException.py", line 7, in wrapper
    with self.some_context_manager(parameter):
  File "...\TestException.py", line 23, in <module>
    test = example.get_property_value()

(paths edited for privacy)

User Settings

languageServer: "Jedi"

Extension version: 2022.12.1
VS Code version: Code 1.70.1 (6d9b74a70ca9c7733b29f0456fd8195364076dda, 2022-08-10T06:08:33.642Z)
OS version: Windows_NT x64 10.0.19044
Modes:

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz (8 x 2304)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.73GB (7.64GB free)
Process Argv
Screen Reader	no
VM	0%

[damien135]

It's been a month and there is no response yet on my report above. Should I provide more information? Am I supposed to add labels to this report? (If so, how?) Please let me know if this is not the right place for this bug report.

[brettcannon]

So sorry for not getting back to you, @damien135 ! It looks like GitHub Actions messed up and didn't run to add our triage-needed label, so this fell through the cracks. I am moving this over to debugpy now to see if they know what's going on.

[fabioz]

Actually, I was checking it here and it should hit as a User uncaught exception (the definition of that is whenever there's an exception from user code which would be raised into the standard library the exception should be shown).

In this case the some_context_manager (user code) would be raised into contextlib (standard library), which is correct.

i.e.:

So, this isn't really a bug (as it's doing what's intended).

Still, I can see how it can be argued that User uncaught exception should only be handled if the exception when it goes into the standard library code and it'd not cross back to user code anymore.

So, maybe this could be turned into a feature request for that behavior, still, the question is whether we should have yet another breakpoint type for that or if this should be a flag or whether the current behavior is never valid and only that one should be used...

[fabioz]

-- Another possibility would be just making an exception for contexlib...

[damien135]

Hello Fabioz, thanks for looking into this and for the technical explanation. I'd just like to point out that this was highly confusing to me during debugging. I expected this exception to be caught by the try/except block and therefore be 'silenced'. So I was facing an exception where I didn't want the debugger to break (I just wanted it to be handled by the try/except block), but I wasn't able to "silence" it by any means except by disabling breaks on every other "uncaught" exception as well in the debugger (which I didn't want to do).

Since Python encourages the use of exceptions (EAFP principle), I feel like the pattern I described here isn't too weird to use. I'd argue that what makes most sense here is that the debugger doesn't break. Otherwise, how do I keep working on other parts of this project (where I want to break on uncaught exceptions) without constantly being interrupted by this code snippet (which works as intended and where I just want to trigger particular behavior if an exception is thrown upstream)?