What are Preconditions and Postconditions?
Preconditions and postconditions explained — caller obligations vs method guarantees in Design by Contract — with a Java example and Q&A.
Expected Interview Answer
A precondition is a condition that must be true before a method is called for that method to behave correctly, and a postcondition is a condition the method guarantees will be true after it returns, provided the precondition held — together they form the caller-facing part of a method’s contract.
Preconditions constrain the caller: things like argument ranges, required object state, or non-null requirements that the caller is responsible for satisfying before invoking the method. Postconditions constrain the callee: what the method promises about its return value, its effects on object state, or side effects, but only if the precondition was actually met — a broken precondition voids the postcondition guarantee entirely. This is the fundamental division of labor in Design by Contract: the caller must uphold preconditions, and in exchange the method must uphold postconditions, so a failure is always attributable to whichever side broke its promise. In practice, preconditions are commonly enforced with argument-validating exceptions (throwing IllegalArgumentException) or assertions, while postconditions are documented as guarantees and sometimes checked with assertions in tests or debug builds.
- Clearly separates caller responsibility from callee responsibility
- Removes ambiguity about what a method promises versus what it merely hopes for
- Makes bugs easier to localize — a broken precondition points at the caller, a broken postcondition points at the method
- Forms the basis for formal specification and contract-based testing
AI Mentor Explanation
Before a bowler can appeal for LBW, the precondition is that the ball must have struck the batter’s pad without first hitting the bat — the appeal is meaningless otherwise. If that precondition holds, the postcondition is that the umpire must render a decision, out or not out, based on ball-tracking rules. Preconditions and postconditions work this same way in code: the precondition is what must be true for the call to make sense, and the postcondition is the guaranteed outcome once it does.
Step-by-Step Explanation
Step 1
State the precondition
Specify exactly what must be true about arguments and object state before calling the method.
Step 2
Enforce it at the boundary
Validate the precondition at the start of the method, typically throwing on violation.
Step 3
Perform the operation
Carry out the method's work, assuming the precondition holds.
Step 4
Guarantee the postcondition
Ensure the documented result or state change is true before returning control to the caller.
What Interviewer Expects
- Correct definitions distinguishing caller obligation (precondition) from callee guarantee (postcondition)
- Recognition that a broken precondition voids the postcondition guarantee
- A concrete code example showing both enforced
- Connection to the broader Design by Contract framework and invariants
Common Mistakes
- Swapping the definitions — thinking preconditions are guarantees and postconditions are caller obligations
- Believing a method must still produce a correct postcondition even if the precondition was violated
- Treating preconditions/postconditions as optional documentation instead of enforceable, testable conditions
- Forgetting to mention that they are the caller/callee halves of a Design by Contract
Best Answer (HR Friendly)
“A precondition is what the caller must make sure is true before calling a method — like passing a valid, non-negative number. A postcondition is what the method promises will be true after it finishes, as long as that precondition was met. It’s basically a two-sided deal: you hold up your end by satisfying the precondition, and the method holds up its end by satisfying the postcondition.”
Code Example
class Rectangle {
private double width, height;
// Precondition: width and height must both be positive
Rectangle(double width, double height) {
if (width <= 0 || height <= 0) {
throw new IllegalArgumentException("precondition violated: dimensions must be positive");
}
this.width = width;
this.height = height;
}
// Precondition: factor must be positive
// Postcondition: area after scaling equals original area * factor^2
void scale(double factor) {
if (factor <= 0) {
throw new IllegalArgumentException("precondition violated: factor must be positive");
}
double areaBefore = width * height;
width *= factor;
height *= factor;
double expectedArea = areaBefore * factor * factor;
assert Math.abs((width * height) - expectedArea) < 1e-9
: "postcondition violated: area did not scale correctly";
}
}Follow-up Questions
- What happens to the postcondition guarantee if the precondition is violated?
- How do preconditions and postconditions relate to a class invariant?
- Should preconditions be enforced with exceptions or assertions, and why?
- How would you document preconditions and postconditions in Javadoc?
MCQ Practice
1. A precondition is an obligation on?
The precondition is something the caller must ensure is true before invoking the method.
2. If a precondition is violated, the postcondition guarantee is?
A broken precondition voids the method's obligation to satisfy its postcondition.
3. A postcondition describes?
A postcondition is the guarantee the method makes about its outcome once the precondition was satisfied.
Flash Cards
Precondition in one line? — What must be true before a method is called, enforced by the caller.
Postcondition in one line? — What the method guarantees is true after it returns, given the precondition held.
Effect of a broken precondition? — It voids the method's obligation to satisfy the postcondition.
Where do they fit in Design by Contract? — They are two of the three contract elements, alongside class invariants.