PERF203 should only trigger for exception handler that unconditionally raises

[NeilGirdhar]

I think that PERF203 should only trigger when the exception handler unconditionally raises.

for i in range(10):
    try:
        print(1 / 0)
    except Exception:  # a.py:4:5: PERF203 `try`-`except` within a loop incurs performance overhead
        print("oops")
    print("2")

Although, this is not a priority for me since I decided to disable it. It never caught anything useful for me.

[charliermarsh]

For completeness -- could you give an example of a case that should and shouldn't be caught, based on this criteria?

[NeilGirdhar]

Where it should not be caught is, in my opinion constructs like the one displayed above. The problem is that this error can't be acted on for such an example. You can't move the try/except outside the loop since that would make an exception skip everything that follows the try/except.

As for where it should be caught, I think it's tricky because there's a balance. While it is more efficient to have try/except around the loop, it means that more code is protected by the try/except, which is a downside. Ideally, you want the minimum amount of code in a try/except.

I'm not sure what others like, but personally I don't find this error useful in the first place since it is trying to add more code to the try/except.