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

False positive for raising-non-exception #2751

Closed
ian-h-chamberlain opened this issue Feb 14, 2019 · 1 comment
Closed

False positive for raising-non-exception #2751

ian-h-chamberlain opened this issue Feb 14, 2019 · 1 comment

Comments

@ian-h-chamberlain
Copy link

Possibly related to #2431, but doesn't seem to be exactly the same since that was resolved and is more related specifically to tuple exception catching. I'm not sure if Pylint should be able to handle this case, as it would appear to require some evaluation of control flow, but I encountered it in some test code where a variable may contain either an exception or some other object type. If this is a known limitation of the static analysis Pylint is doing then by all means feel free to close it.

Steps to reproduce

  1. Run pylint agains the following minimal example:
"""repro.py"""


#  pylint: disable=too-few-public-methods
class MyObject:
    """some object type"""


def _minimal_repro_example(index):
    objects = ['foo']

    try:
        maybe_exception = objects[index]
    except IndexError:
        maybe_exception = MyObject()

    if isinstance(maybe_exception, Exception):
        raise maybe_exception

    return maybe_exception

The relevant line seems to be maybe_exception = MyObject(). Replacing it with maybe_exception = 'foo' will no longer report an error.

Current behavior

Pylint reports an error:

$ pylint repro.py
************* Module repro
repro.py:18:8: E0710: Raising a new style class which doesn't inherit from BaseException (raising-non-exception)

Expected behavior

Pylint does not report an error

pylint --version output

pylint 2.2.2
astroid 2.1.0
Python 3.6.5 (default, Jan 29 2019, 13:07:11)
[GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5)]

Also reproduced with the following setup:

pylint 2.3.0-dev1
astroid 2.2.0-dev
Python 3.6.5 (default, Jan 29 2019, 13:07:11)
[GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5)]
@PCManticore
Copy link
Contributor

Hey @ian-h-chamberlain Thanks for reporting this thorough issue! Yep, as you already mentioned, this is a known limitation of pylint, we currently don't have proper control flow understanding, so in your example, the if guard is not taken in consideration. Here's another older issue on the same topic #157. I'm going to close this for now, but I'm hoping that at some point these issues will all be closed.

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

2 participants