This pull request closes #9, by adding the PreconditionError and PostconditionError exception types, both subclasses of AssertionError. This is a backwards-compatible change, with two benefits:
All users can see at a glance whether the error arose from a contract or from an internal assertion. For contract violations, it is also obvious whether the violation was of a precondition or a postcondition. This can make localizing bugs substantially easier, especially where the codebase is partly covered by contracts and partly by traditional assertions.
Because precondition violations can be distinguished from other errors, test frameworks and fuzzers can optionally skip or retry tests with invalid input. For a concrete example, this patch would enable the fulfill decorator proposed in HypothesisWorks/hypothesis#1474 - which in turn would improve the ergonomics of testing internal functions where input would usually be sanitized at a boundary layer.
deadpixi
commented
6 years ago
This pull request closes #9, by adding the
PreconditionErrorandPostconditionErrorexception types, both subclasses ofAssertionError. This is a backwards-compatible change, with two benefits:All users can see at a glance whether the error arose from a contract or from an internal assertion. For contract violations, it is also obvious whether the violation was of a precondition or a postcondition. This can make localizing bugs substantially easier, especially where the codebase is partly covered by contracts and partly by traditional assertions.
Because precondition violations can be distinguished from other errors, test frameworks and fuzzers can optionally skip or retry tests with invalid input. For a concrete example, this patch would enable the
fulfilldecorator proposed in HypothesisWorks/hypothesis#1474 - which in turn would improve the ergonomics of testing internal functions where input would usually be sanitized at a boundary layer.