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
change assertRaises message when wrong exception is raised #87762
Comments
Right now, this code: class FooError(Exception): pass
class BarError(Exception): pass
def test_me(self):
with self.assertRaises(FooError):
raise BarError("something") will have the error "BarError: something" with no indication that an exception was expected but just that we got the wrong one. It would be help to change the message to something like: Expected exception of type FooError but exception BarError('something') was raised. |
What you are suggesting replaces the type of the exception being raised. If it's something like a MemoryError or KeyboardInterrupt you don't want that, you want your test process to terminate. |
Another way to look at it is that your test has two problems. One is that the expected exception didn’t happen and the other is that an unexpected exception happened. The two problems are usually unrelated, and trying to conflate them into one error message can be confusing in some cases. When a test has multiple problems you get an error for the first one. |
I concur with Irit. The test is failed in any case, so you need to look at the code to fix it. For the same reason we do not have assertNotRaises(). |
I think I understand where the request comes from: in the case where you've changed the exception type that an API is expected to raise, and you've either updated the test to check for the new exception type and missed an update in the business logic, or vice versa, you'd like the test to tell you that the wrong exception type was raised. I've definitely done this myself on more than a few occasions. So this *particular* case is an exception to Irit's observation that "The two problems are usually unrelated [...]". But I think it *is* an exception: I agree that the rule holds in general, and that the current behaviour shouldn't be changed. I think we've got sufficient agreement from core devs to close here. |
I agree. That’s what the “usually” was for. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: