-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[pydoclint
] Teach rules to understand reraised exceptions as being explicitly raised
#12639
Conversation
…explicitly raised
fn extract_raised_exception<'a>( | ||
semantic: &SemanticModel<'a>, | ||
exc: &'a Expr, | ||
) -> Option<QualifiedName<'a>> { | ||
if let Some(qualified_name) = semantic.resolve_qualified_name(exc) { | ||
return Some(qualified_name); | ||
} | ||
if let Expr::Call(ast::ExprCall { func, .. }) = exc { | ||
return extract_raised_exception(semantic, func.as_ref()); | ||
} | ||
None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got rid of this helper by using map_callable()
before passing the node to resolve_qualified_name
in visit_stmt
|
code | total | + violation | - violation | + fix | - fix |
---|---|---|---|---|---|
DOC501 | 109 | 109 | 0 | 0 | 0 |
Summary
Fixes #12630.
DOC501 and DOC502 now understand functions with constructs like this to be explicitly raising
TypeError
(which should be documented in a function's docstring):I made an exception for
Exception
andBaseException
, however. Constructs like this are reasonably common, and I don't think anybody would say that it's worth putting in the docstring that it raises "some kind of generic exception":Test Plan
cargo test -p ruff_linter --lib