I have been interested in better coding practices/methods which makes the reliability and maintenance less painful effort. I read the chapter about Design by Contract on "Object Oriented Software Construction" by Bertrand Meyer. Despite the fact that, there are many definition and discussion about "Defensive Programming", I have problems in understanding the key differences and benefits.

As far as I understood, DbC supports preconditions and says it is redundant to check any input parameter because (or if) they are preconditions. It is the responsibility of caller (client) to check the validity of these inputs. However, many widely used programming languages like C++, Java and etc. do not have a built-in contract system (like Eiffel) and third party support depends on assertions or exceptions. Is it okay to check these conditions on the supplier side and test it like that due to the lack of this built-in support?

I think input validation is a part of "Defensive Programming" approach (at least people think in that way?) which is also a kind of precondition check with the third party contract support I mentioned in the above paragraph. I think, in case of an invalid input - according to preconditions - throwing exception(s) for invalid inputs (which are also against preconditions) is a common case. If supplier mentioned valid inputs as a precondition (via javadoc and etc.), isn't it a redundant check? If we follow DbC, should we remove such kind of checks, because this is the responsibility of the client? I assume supplier code has required methods for preconditions to be checked by client.

At last, I believe in different problems may require different solutions and there is no ultimate answer. However, in that caseit is hard for me to separate these concepts.

  • I read this thread. Unfortunately, I could not satisfied from the answers. They mention who will/should do what, but how? Or these ideas applicable for almost every case? Especially the lack of built-in support in programming languages and redundant checks are critical points for me. I am not talking about every parts of Defensive Programming when I compare with DbC. – Deniz Feb 12 '15 at 16:46
  • meta.stackexchange.com/a/194495/165773 – gnat Feb 12 '15 at 17:08
  • "It is the responsibility of caller (client) to check the validity of these inputs" - nope, it is the responsibility of the contract system, which sits between the caller and the called method. If the programming language has no contract system, input validation inside the called function is the probably the best alternative you have, and yes, that's a form of Defensive programming. I think this is pretty clear from that other question and the square root example in the top answer. – Doc Brown Feb 12 '15 at 17:49
  • @DocBrown , in the first answer there is a note which says "Note: it is of course possible that in DbC someone else will check the contract". I could not get any sentence that, directly/explicitly mention that contract system should do the job. drdobbs.com/an-exception-or-a-bug/184401686 is an example for usage of assert as a checking mechanism. Moreover, in languages which are lack of such a contract system, use assertions or exceptions within their third party support. This can be done on the supplier code (assert/exception), which you say in the domain of Defensive Programming. – Deniz Feb 13 '15 at 8:25
  • So, again digging my confused mind, it is waste of time to talk about DbC for languages, which do not have a built-in contract system. All other efforts are useless/hopeless? – Deniz Feb 13 '15 at 8:27