-
Notifications
You must be signed in to change notification settings - Fork 2k
Description
Red-knot currently doesn't emit a diagnostic on this snippet:
raise 42But we should, since 42 is not a valid object to be used in a raise statement:
>>> raise 42
Traceback (most recent call last):
File "<python-input-0>", line 1, in <module>
raise 42
TypeError: exceptions must derive from BaseExceptionThe rule is that the object used in a raise statement must have a type that is assignable to the type BaseException | type[BaseException], since both of the following work:
>>> raise ValueError
Traceback (most recent call last):
File "<python-input-1>", line 1, in <module>
raise ValueError
ValueError
>>> raise ValueError()
Traceback (most recent call last):
File "<python-input-2>", line 1, in <module>
raise ValueError()
ValueErrorWe need to add some extra logic to this branch here:
ruff/crates/red_knot_python_semantic/src/types/infer.rs
Lines 2193 to 2201 in c9fdb1f
| fn infer_raise_statement(&mut self, raise: &ast::StmtRaise) { | |
| let ast::StmtRaise { | |
| range: _, | |
| exc, | |
| cause, | |
| } = raise; | |
| self.infer_optional_expression(exc.as_deref()); | |
| self.infer_optional_expression(cause.as_deref()); | |
| } |
I think this will probably need to be a new rule added to https://github.com/astral-sh/ruff/blob/main/crates/red_knot_python_semantic/src/types/diagnostic.rs ? I don't think it fits neatly into any other rule. The alternative might be to make the existing INVALID_EXCEPTION_CAUGHT rule broader (and rename it).