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

OutcomeException should not be a subclass of Exception #580

Closed
pytestbot opened this issue Sep 4, 2014 · 6 comments
Closed

OutcomeException should not be a subclass of Exception #580

pytestbot opened this issue Sep 4, 2014 · 6 comments
Labels
Milestone

Comments

@pytestbot
Copy link
Contributor

@pytestbot pytestbot commented Sep 4, 2014

Originally reported by: BitBucket: thiefmaster, GitHub: thiefmaster


Imagine this code:

def blackbox(callback, arg):
    # this is assumed to be application code
    try:
        callback(arg)
    except Exception:
        pass


def test_callback():
    def cb(x):
        if not x:
            import pytest
            pytest.fail('foo')

    blackbox(cb, True)
    blackbox(cb, False)

The testcase will pass since except Exception will catch the Failed raised by pytest.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 a try...except Exception block to prevent an email sending failure from breaking things (e.g. because the email is not very important). So now the pytest.fail called in the monkeypatched method will never propagate since it's caught by application code.


@pytestbot
Copy link
Contributor Author

@pytestbot pytestbot commented Sep 8, 2014

Original comment by Floris Bruynooghe (BitBucket: flub, GitHub: flub):


When following this route, how can one also protect agains try: callback(); except: pass, that is a bare exception in user code?

(I must admit I've never tried to call pytest.fail() in callbacks before)

@pytestbot
Copy link
Contributor Author

@pytestbot pytestbot commented Sep 8, 2014

Original comment by BitBucket: thiefmaster, GitHub: thiefmaster:


That's such an unlikely case though...

@pytestbot pytestbot added the type: bug label Jun 15, 2015
@RonnyPfannschmidt RonnyPfannschmidt added this to the 2.8 milestone Sep 13, 2015
@RonnyPfannschmidt
Copy link
Member

@RonnyPfannschmidt RonnyPfannschmidt commented Sep 13, 2015

@flub
its sensible to use BaseException to help people

we don't need to protect about the diaper antipattern

@RonnyPfannschmidt RonnyPfannschmidt modified the milestones: 2.8, 2.8.dev Sep 18, 2015
@nicoddemus
Copy link
Member

@nicoddemus nicoddemus commented Sep 25, 2015

Shouldn't this be in 2.9.0? It's not a bug per-se, but an improvement that might even break current test suites, IMO.

@RonnyPfannschmidt RonnyPfannschmidt modified the milestones: 3.0, 2.8.1 Sep 26, 2015
@The-Compiler
Copy link
Member

@The-Compiler The-Compiler commented Aug 5, 2016

Changing the milestone for this to 4.0 for now.

@The-Compiler The-Compiler modified the milestones: 4.0, 3.0 Aug 5, 2016
RonnyPfannschmidt added a commit to RonnyPfannschmidt/pytest that referenced this issue Jun 11, 2017
RonnyPfannschmidt added a commit to RonnyPfannschmidt/pytest that referenced this issue Jun 11, 2017
RonnyPfannschmidt added a commit to RonnyPfannschmidt/pytest that referenced this issue Jun 11, 2017
RonnyPfannschmidt added a commit to RonnyPfannschmidt/pytest that referenced this issue Jun 11, 2017
RonnyPfannschmidt added a commit to RonnyPfannschmidt/pytest that referenced this issue Jun 11, 2017
RonnyPfannschmidt added a commit to RonnyPfannschmidt/pytest that referenced this issue Jun 11, 2017
RonnyPfannschmidt added a commit to RonnyPfannschmidt/pytest that referenced this issue Jun 11, 2017
nicoddemus added a commit that referenced this issue Jul 30, 2017
Test Outcomes as BaseException - fix #580
@nicoddemus nicoddemus closed this in 06a4933 Aug 1, 2017
blueyed added a commit to blueyed/pytest-django that referenced this issue Aug 21, 2017
This shows issue pytest-dev/pytest#580, which
is fixed in pytest 3.2.1.
blueyed added a commit to blueyed/pytest-django that referenced this issue Aug 21, 2017
This shows issue pytest-dev/pytest#580, which
is fixed in pytest 3.2.0.
miketheman added a commit to miketheman/pytest-socket that referenced this issue Sep 6, 2017
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 <miketheman@gmail.com>
miketheman added a commit to miketheman/pytest-socket that referenced this issue Sep 6, 2017
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 <miketheman@gmail.com>
blueyed added a commit to pytest-dev/pytest-django that referenced this issue Oct 22, 2017
This shows issue pytest-dev/pytest#580, which
is fixed in pytest 3.2.0.
timb07 added a commit to timb07/pytest-django that referenced this issue May 26, 2018
@blueyed
Copy link
Contributor

@blueyed blueyed commented May 7, 2019

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 Exception (pytest-dev/pytest-asyncio#123).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants