pytest-dev/pytest · error · ValueError

Expected an exception type or a tuple of exception types…

Error message

Expected an exception type or a tuple of exception types, but got `{expected_exception!r}`. Raising exceptions is already understood as failing the test, so you don't need any special code to say 'this should never raise an exception'.

What it means

Thrown by pytest.raises() in the function-call form (expected_exception + func) when expected_exception is falsy: None, False, 0, empty tuple, etc. pytest can't assert that 'no exception' occurs this way since test failure already implies that.

Solutions

Pass a concrete exception class or tuple of classes.
If you expect no exception, just call the function directly (test fails if it raises).
Guard with `if expected_exception is not None:` before calling pytest.raises.

Example fix

// before
exc = get_exc_type()  # may return None
pytest.raises(exc, func)
// after
exc = get_exc_type()
assert exc is not None, "expected exception type required"
pytest.raises(exc, func)

Defensive patterns

Strategy: validation

Validate before calling

if not expected_exception:
    raise ValueError('pytest.raises needs a real exception type, not a falsy value')
pytest.raises(expected_exception, func)

Type guard

def is_exception_type(e: object) -> bool:
    return isinstance(e, type) and issubclass(e, BaseException)

Prevention

Pass a concrete exception class or tuple of classes.
If you expect no exception, call the function directly.
Guard dynamically-computed exception types with an assert before passing.

When it happens

Trigger: Calling pytest.raises(None, func) or pytest.raises((), func); a variable holding an exception type that resolved to None; pytest.raises(False, some_callable).

Common situations: Conditionally computing an expected exception that ended up None; refactoring where the exception type was moved; misunderstanding that pytest.raises is for asserting exceptions ARE raised.

Related errors

AI-assisted analysis of pytest-dev/pytest@0d6fbdeffa (2026-08-11). Data as JSON: /api/errors/d1b5b239cd32d4d1. Report an issue: GitHub.

Appendix: source

Thrown at src/_pytest/raises.py:269

        frame) alive until the next cyclic garbage collection run.
        More detailed information can be found in the official Python
        documentation for :ref:`the try statement <python:try>`.
    """
    __tracebackhide__ = True

    if func is None and not args:
        if set(kwargs) - {"match", "check", "expected_exception"}:
            msg = "Unexpected keyword arguments passed to pytest.raises: "
            msg += ", ".join(sorted(kwargs))
            msg += "\nUse context-manager form instead?"
            raise TypeError(msg)

        if expected_exception is None:
            return RaisesExc(**kwargs)
        return RaisesExc(expected_exception, **kwargs)

    if not expected_exception:
        raise ValueError(
            f"Expected an exception type or a tuple of exception types, but got `{expected_exception!r}`. "
            f"Raising exceptions is already understood as failing the test, so you don't need "
            f"any special code to say 'this should never raise an exception'."
        )
    if not callable(func):
        raise TypeError(f"{func!r} object (type: {type(func)}) must be callable")
    with RaisesExc(expected_exception) as excinfo:
        func(*args, **kwargs)
    try:
        return excinfo
    finally:
        del excinfo


# note: RaisesExc/RaisesGroup uses fail() internally, so this alias
#  indicates (to [internal] plugins?) that `pytest.raises` will
#  raise `_pytest.outcomes.Failed`, where
#  `outcomes.Failed is outcomes.fail.Exception is raises.Exception`

View on GitHub (pinned to 0d6fbdeffa)