Could Designing by Contract (DbC) be a way to program defensively?

Is one way of programming better in some cases than the other?

2 Answers 2


Design by Contract and defensive programming are in some sense opposites of each other: in DbC, you define contracts between collaborators and you program under the assumption that the collaborators honor their contracts. In defensive programming, you program under the assumption that your collaborators violate their contracts.

A real square root routine written in DbC style would state in its contract that you aren't allowed to pass in a negative number and then simply assume that it can never encounter a negative number. A real square root routine written defensively would assume that it is passed a negative number and take appropriate precautions.

Note: it is of course possible that in DbC someone else will check the contract. In Eiffel, for example, the contract system would check for a negative number at runtime and throw an appropriate exception. In Spec#, the theorem prover would check for negative numbers at compile time and fail the build, if it can't prove that the routine will never get passed a negative number. The difference is that the programmer doesn't make this check.


Could Designing by Contract (DbC) be a way to program defensively?


"Defensive Programming" is often an excuse to waste time. It often wastes time checking for things that will cause ordinary exceptions. Instead of the exceptions, extra IF statements are written instead of exception-handling clauses.

Define the contract and be done with it.

When someone violates the contract, the program will -- in the normal course of events -- break and raise normal exceptions which can be normally handled.

"Defensive programming" and "Error prevention" can be shown to add errors (because the error prevention checks are themselves erroneous) rather than prevent errors.

Exception handling can silence, log and handle an exception far better than "Defensive Programming".

  • 7
    Defensive programming is moe than just if statements. It includes code reviews, static analysis, security audits, secure coding guidelines, and more. In addition, the use of exceptions and exception handling (as opposed to simply letting the program crash and burn) is considered a defensive programming technique.
    – Thomas Owens
    Dec 15, 2011 at 16:05
  • 2
    @ThomasOwens: That sounds like "Good Software Development". I've only ever seen defensive programming used as an excuse to write lots of IF statements (or assertions) that fail before exceptions are normally raised. I wouldn't call your long list of really good ideas "Defensive Programming". I'd call your list of good ideas "Programming". That way we can separate time-wasting from all the smart things you list.
    – S.Lott
    Dec 15, 2011 at 16:08
  • 2
    I prefer to call those "good ideas when writing code" myself, but when I was taught about defensive programming, I was taught that it referred to any and all techniques with the express purpose of ensuring the safety, security, and reliability of a system. Maybe that's an overly broad definition, or perhaps it's a wrong definition, but it is what I was taught. I have seen people call if statements and assertions "defensive programming", but based on the definition I was taught, I wouldn't call it such (except in cases where you don't necessarily have better options, like exceptions).
    – Thomas Owens
    Dec 15, 2011 at 16:11
  • @ThomasOwens: "Maybe that's an overly broad definition". Agree. It seems like a great checklist of good ideas.
    – S.Lott
    Dec 15, 2011 at 16:12
  • 2
    -1: I don't see how DbC is a way to program defensively, they're basically opposites. I doubt it's common to do defensive programming just to waste time. And 'can be shown to add errors' needs a citation because it's not at all obvious.
    – Mark
    Nov 24, 2017 at 15:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.