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

docparams check doesn't understand class hierarchies #4955

Closed
kasium opened this issue Sep 2, 2021 · 5 comments · Fixed by #5278
Closed

docparams check doesn't understand class hierarchies #4955

kasium opened this issue Sep 2, 2021 · 5 comments · Fixed by #5278
Labels
Enhancement ✨ Improvement to a component False Positive 🦟 A message is emitted but nothing is wrong with the code
Milestone

Comments

@kasium
Copy link
Contributor

kasium commented Sep 2, 2021

Bug description

class MyError(ValueError):
    pass

def foo():
    """Foo method

    Raises:
        ValueError: all the time
    """
    raise MyError()

Configuration

No response

Command used

pylint x.py --disable all --load-plugins pylint.extensions.docparams --enable missing-raises-doc

Pylint output

************* Module x
x.py:5:0: W9006: "MyError" not documented as being raised (missing-raises-doc)

------------------------------------------------------------------
Your code has been rated at 7.50/10 (previous run: 2.50/10, +5.00)

Expected behavior

No error;

I understand that checking the hierarchy is more complicated, but I guess there are valid use cases to expose only a general exception

Pylint version

pylint: 2.10.2
astroid: 2.7.3
python: 3.7.1

OS / Environment

Linux

Additional dependencies

No response

@kasium kasium added Bug 🪲 Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling labels Sep 2, 2021
@Pierre-Sassoulas Pierre-Sassoulas added Enhancement ✨ Improvement to a component False Positive 🦟 A message is emitted but nothing is wrong with the code and removed Bug 🪲 Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling labels Sep 2, 2021
@kasium
Copy link
Contributor Author

kasium commented Nov 2, 2021

@Pierre-Sassoulas I would like to give it a try.

My current idea is to enhance pylint/extensions/_check_docs_utils.py::possible_exc_types to not only return the names of the exceptions, but the whole exception hierarchy. Or, as an alternative, it can return a set of nodes instead of strings to check later the hierarchy.

But, I currently struggle to get the super class of a given exception class. Any idea?

@Pierre-Sassoulas
Copy link
Member

I think ClassDef nodes in astroid have a parents or ancestor attributes. You can check the doc or the astroid code directly to confirm.

@kasium
Copy link
Contributor Author

kasium commented Nov 2, 2021

@Pierre-Sassoulas thanks a lot. Found it.

By any chance, do you know why astroid.Instance is checked here? https://github.com/PyCQA/pylint/blob/6a7209b9b8b9bbd0fdf08ce22daf325c9d0d28ec/pylint/extensions/_check_docs_utils.py#L162

I already removed the type and ran pytest tests/extensions/test_check_raise_docs.py which didn't showed any failing test. No clue how to handle that type

@Pierre-Sassoulas
Copy link
Member

I don't know, you could try to check the git history of this particular line. See https://stackoverflow.com/a/19757493/2519059

@kasium
Copy link
Contributor Author

kasium commented Nov 3, 2021

Already done. I found the commit adding it but there was no explanation why this is needed. Let me further check

DanielNoord added a commit that referenced this issue Dec 14, 2021
Before, missing-raises-doc could not understand class hierarchies but just compared names.
So, when a method documented a raise of a parent class, but a child exception was raised, the check failed.

With this change, if the name compare doesn't help, the exception class hierarchy is checked.
For that, possible_exc_types was changed to return classes instead of names

Resolved #4955

Co-authored-by: Pierre Sassoulas <[email protected]>

Co-authored-by: Daniël van Noord <[email protected]>
@DanielNoord DanielNoord added this to the 2.13.0 milestone Dec 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement ✨ Improvement to a component False Positive 🦟 A message is emitted but nothing is wrong with the code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants