Skip to content
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

[Proposal] Allow disabling "try-except" clauses evaluation. #98

Closed
CaBazaga opened this issue Apr 4, 2022 · 1 comment
Closed

[Proposal] Allow disabling "try-except" clauses evaluation. #98

CaBazaga opened this issue Apr 4, 2022 · 1 comment

Comments

@CaBazaga
Copy link

CaBazaga commented Apr 4, 2022

When using third party services libraries, or even on your own code, you may find a scenario were a function may return several different types of exceptions each of them requiring a simple but different action to be taken.

Exhaustive Exception treatment on those cases leads to a high complexity result which is right, as per the complexity calculation strategy, but an undesired result.

def foo(bar):
    try:
        do_whatever(bar)
    except TypeA:
        do_something_related_to_TypeA()
    except TypeB:
        do_something_related_to_TypeB()
    except TypeC:
        do_something_related_to_TypeC()
    except TypeD:
        do_something_related_to_TypeD()
    except TypeE:
        do_something_related_to_TypeE()
    except TypeF:
        do_something_related_to_TypeF()
    except TypeG:
        do_something_related_to_TypeG()
    except TypeH:
        do_something_related_to_TypeH()
    except TypeI:
        do_something_related_to_TypeI()
    except TypeJ:
        do_something_related_to_TypeJ()
python -Bm mccabe deffoobar.py                     
1:0: 'foo' 12

It will be interesting being able to ignore exceptions branching to properly compute the complexity of the actual function logic without the burden of the exception treatment one.

@sigmavirus24
Copy link
Member

I don't think allowing folks to choose what contributes to complexity globally is really something we want to introduce. We wouldn't be even considering this on a "per-block" basis so it would be a global option and I think that's going to actively thwart the reason people bother using McCabe

@asottile asottile closed this as completed Dec 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants