Design by Contract says, in terms of the function talking: "you give me all the right parameters and I'll give you exactly this kind of data" ...in essence.

So, given that, should I use up resources checking the output? I should check for properties that the function does not guarantee its output possesses, but the properties the function guarantees need not be checked, right?

Here's an example:

class Transition_Manager {
    string str = generate_non_null_string();
    process_using_a_function_that_can't_handle_null_strings( str );

4 Answers 4


The Design-by-Contract methodology makes clear separation of responsibilities:

  • a client has to fulfill a precondition of a supplier
  • a supplier has to fulfill its postcondition as soon as the precondition is fulfilled

As a result of this policy

  • if the precondition is violated, it is a fault of the client (the client is "guilty", it is a bug in the client's code)
  • if the postcondition is violated, it is a fault in the supplier (the supplier is "guilty", it is a bug in the supplier's code)

That's why it is called "contract" - it is a contract/an agreement between two parties - the client and the supplier - to meet these conditions.

From the client's point of view, it has to fulfil the precondition, but then it can rely on the postcondition that is an obligation of the supplier. There is no need to recheck the output.

In real life it is up to the author(s) of the supplier code how to make sure the output is always correct as soon as the input is correct, be it debugging, testing, verification, code review or something else. In the environments that support DbC natively, it is possible to perform run-time monitoring of preconditions and postconditions during program execution. Contract violation immediately points to the party that is buggy.


if you take information from untrusted sources (network, user) then you should check it all

that said that said binary search would never be able to work without the (unchecked) assumption of the array being sorted. if you checked sorted-ness then you might as well do a linear search.

most important is being able to fail gracefully if you do get wrong data, debugging is much easier when there is a nice exception and related log to look at.

  • I think I get what you mean, because the functions are contracted to provide data with specific properties, any extra requirements that I need for the proper integration of said function, is my responsibility to check Apr 4, 2014 at 18:53

Consider validating the output of your function before runtime.

You can do this by writing unit tests that validate the output of your function for all the known valid inputs (or maybe just a representative subset of valid inputs if the full set is too large).

This offsets the cost of data validation from your application to your development process.

This works particularly well if you have something like a Continuous Integration server set up to automatically run your tests.

  • then does that mean, throw an exception for all unknown inputs? Apr 4, 2014 at 18:49
  • That's kind of unrelated, but could be a good thing. It all really depends on what your error handling strategy is. If failing early on bad data is important then, by all means, throw exceptions when the preconditions haven't been met. If you have another strategy for dealing with failure, where exceptions would be overkill, then don't.
    – MetaFight
    Apr 4, 2014 at 19:29

As an API writer you should validate that the inbound parameters meet your processing criteria before you proceed, regardless of who you think is calling you.

As an API consumer, you should verify that the results meet you processing needs regardless of how safe you think the API is.

When writing code, trust is overrated.

  • 2
    The whole point of Design-by-Contract is to not do this, but to establish a clear formal contract between caller and callee to exactly avoid having to check everything everywhere. Apr 5, 2014 at 0:34
  • Understood, but that doesn't change the fact you can get bad inputs and should check your data based on the needs of your environment. Bad things can happen when bad data is ignored. Maybe the right answer is not to use DbC if hard failures are unacceptable.
    – cdkMoose
    Apr 7, 2014 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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