This question already has an answer here:
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.