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

User exceptions are ignored if data is frozen #4132

Open
jakkdl opened this issue Oct 8, 2024 · 0 comments
Open

User exceptions are ignored if data is frozen #4132

jakkdl opened this issue Oct 8, 2024 · 0 comments

Comments

@jakkdl
Copy link
Contributor

jakkdl commented Oct 8, 2024

def test_frozen_things():
    # Hypothesis reraises the TypeError as a StopTest, because the data is Frozen.
    @given(st.data())
    def foo(data):
        data.conjecture_data.freeze()
        raise TypeError("oops")

    foo()

It should be possible to repro without manually freezing the data as well, especially if invoking async stuff.

Offending lines:

except failure_exceptions_to_catch() as e:
# If an unhandled (i.e., non-Hypothesis) error was raised by
# Hypothesis-internal code, re-raise it as a fatal error instead
# of treating it as a test failure.
filepath = traceback.extract_tb(e.__traceback__)[-1][0]
if is_hypothesis_file(filepath) and not isinstance(e, HypothesisException):
raise
if data.frozen:
# This can happen if an error occurred in a finally
# block somewhere, suppressing our original StopTest.
# We raise a new one here to resume normal operation.
raise StopTest(data.testcounter) from e

Possible fixes:

  1. reraise the exception saved in StopTest.__cause__ when the StopTest is handled. I'm getting ~8 hits for except StopTest in non-test code though, so could get messy.
    • might be better to save the exception in the DataObject
  2. Traverse e.__context__ to see if we actually did raise Stoptest before handling. Although this would still suppress user errors in teardown if we did raise Stoptest, so it's only a partial fix. (edit: except the test_error_is_in_finally test works.. so maybe this would fix it???)

Git blame shows ac0d02a as adding the logic. Though I don't understand the code intimately enough to see what the difference between their added test, which ultimately reraises their ValueError, and mine is.

See discussion in #4110 (comment)

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

No branches or pull requests

1 participant