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
type: bug problem that needs to be addressed
Milestone

Comments

@pytestbot
Copy link
Contributor

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

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

Original comment by BitBucket: thiefmaster, GitHub: thiefmaster:


That's such an unlikely case though...

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

@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

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

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
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 <[email protected]>
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 <[email protected]>
blueyed added a commit to pytest-dev/pytest-django that referenced this issue Oct 22, 2017
timb07 pushed a commit to timb07/pytest-django that referenced this issue May 26, 2018
@blueyed
Copy link
Contributor

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).

beyondgeeks added a commit to beyondgeeks/django-pytest that referenced this issue Sep 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug problem that needs to be addressed
Projects
None yet
Development

No branches or pull requests

5 participants