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 );
}
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.
1
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.
2
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