Visual Studio 2022 keeps breaking on exception which seems to be handled in Python internally

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work]
I want to debug my Python application with Visual Studio 2022 Pro - we're just evaluating it for our purpose - and am just configuring the solution. I've stumbled upon a very persistant exception, which breaks execution every time I debug my application and it is annoying that I have to continue several times before the application actually runs.

The minimum sample to preproduce the issue looks like this:

import enum
class MyParentClass(enum.Enum):
    def __getattribute__(self, item):
        return super().__getattribute__(item)

class MyEnum(MyParentClass):
    OPTION1 = 1
    OPTION2 = 2
    OPTION3 = 3

What happens is that return super().__getattribute__(item) throws AttributeError exception several times. This seems all to be part of some internal Python logic. I got to the point just before the exception and it looks like this exception is triggered in enum.py, specifically __new__ function, which calls hasattr(enum_member, '_value_').

I couldn't go deeper with the debugger, as it seems this part is not implemented in Python. But considering how the code executes normally afterwards, as if the exception wasn't thrown at all, I'm guessing there is some internal code, which handles this exception.

The main problem seems to be that Visual Studio seems to think this is an unhandled exception and breaks there unconditionally. I tried disabling all exceptions, so it wouldn't break on any, but what I see is that it breaks only on unhandled exceptions. So I'm guessing this is the gist of the problem. I also tried toggling the option Enable Just My Code, but it made no difference in this case.

If I execute this code without a debugger it finishes without any unhandled exceptions.
Other debuggers, such as PyCharm which we are using at the moment, by default do not break on this exception.

This is a blocker for our team, as we don't want to deal with these breaks every time we start debugging our application.
Is there a way to prevent this behavior? If not, do you have a plan to fix it?

---

Original Comments

Feedback Bot on 3/3/2023, 00:06 AM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[StellaHuang95]

Hi @int19h, do you know if there's a way to not break on this exception in VS?

[int19h]

The fundamental problem here is that it is not known at the point where exception is thrown in Python whether it will be handled or not, because the exception system is one-pass rather than two-pass (as in e.g. C++ or C#). The debugger approximates it by looking at the call stack and inspecting bytecode to see which try-except blocks are currently active. But exceptions can also be handled in native code, and that's what CPython itself does in this case.

Thus, as things stand, the only workaround is to disable reporting that particular exception class entirely - in VS, you can do it via Debug -> Windows -> Exception Settings.

Now, it might be possible to improve the heuristics by looking at more than just try..except blocks - e.g. in this case, the debugger could assume that it's okay for a __getattribute__ frame to raise that particular exception, but report it if and when it shows up in a different frame. However, note that this means that you can also end up suppressing genuine logic errors - e.g. if the implementation of __getattribute__ invokes something else that it does not expect to raise AttributeError; but it does, you'd probably want to know that at the point where it happens. So whatever we do here, I think it needs to be configurable.

[anjav-isystem]

@int19h I already tried disabling all exceptions in the Debug -> Windows -> Exception Settings, but this exception still breaks the debug session. So at the moment we don't have any functional workaround for this (apart from hitting run many times each session).

I'm attaching a screenshot as proof:

[github-actions]

This issue was closed because it has been stalled for 30 days with no activity. If the issue still persists, please reopen with the information requested. Thanks.

[davidair]

This issue is still present in late 2024 with VS 2022 Version 17.11.2. It's very disruptive to the debugging experience.