-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
OutcomeException should not be a subclass of Exception #580
Comments
Original comment by BitBucket: thiefmaster, GitHub: thiefmaster: That's such an unlikely case though... |
@flub we don't need to protect about the diaper antipattern |
Shouldn't this be in |
Changing the milestone for this to 4.0 for now. |
Test Outcomes as BaseException - fix #580
This shows issue pytest-dev/pytest#580, which is fixed in pytest 3.2.1.
This shows issue pytest-dev/pytest#580, which is fixed in pytest 3.2.0.
As of pytest 3.2.0, the internal outcome class no longer inherits from Exception, rather from BaseException. This was reported in pytest-dev/pytest#580 and changed in pytest-dev/pytest#2490 Signed-off-by: Mike Fiedler <[email protected]>
As of pytest 3.2.0, the internal outcome class no longer inherits from Exception, rather from BaseException. This was reported in pytest-dev/pytest#580 and changed in pytest-dev/pytest#2490 Signed-off-by: Mike Fiedler <[email protected]>
This shows issue pytest-dev/pytest#580, which is fixed in pytest 3.2.0.
This shows issue pytest-dev/pytest#580, which is fixed in pytest 3.2.0.
Just for reference/info: using BaseException is problematic, e.g. when people are trying to have a safe repr (and only handling Exception, and where pytest-django might throw a failure for when DB access is not allowed), or with asyncio which only handles |
This shows issue pytest-dev/pytest#580, which is fixed in pytest 3.2.0.
Originally reported by: BitBucket: thiefmaster, GitHub: thiefmaster
Imagine this code:
The testcase will pass since
except Exception
will catch theFailed
raised bypytest.fail
. However, I don't think there is any valid use-case for application code to prevent a testcase failure from propagating to the test runner.A more practical example where this is a major issue is monkeypatching a library function to fail when called. For example, one might want to monkeypatch
smtplib.SMTP.connect
to fail when code tries to send an email unexpectedly - but chances are good that the application is wrapping that code in atry...except Exception
block to prevent an email sending failure from breaking things (e.g. because the email is not very important). So now thepytest.fail
called in the monkeypatched method will never propagate since it's caught by application code.The text was updated successfully, but these errors were encountered: