Good Contract programming idiom?

[Norbert Nemec]

The edited Wikipedia text for D is so far correct, even though the whole 
page is not quite as precise as it could be. The theoretical basis and 
the practical application are somewhat mixed. Fixing that, however, 
would be a major task.

I think the fundamental distinction between three concepts is essential 
in understanding the issue:

* exceptions - handling of run-time conditions caused by user, file, 
network or any other kind of input. Hitting an exception is not a bug 
but a regular function of the code.

* contracts - well designed parts of interfaces. Best understood 
literally as "contract", defining who is responsible for a bug. The 
possibility to check a contract at runtime is actually a secondary function.

* assertions - best understood as "comments" that can be checked by the 
compiler. Sprinkle them freely wherever you find some non-trivial 
relation between variables of the code.

I guess this whole issue simply is something that has to be discussed 
more frequently to make people aware of it.

Greetings,
Norbert




bearophile wrote:
> Norbert Nemec:
> 
>> No! No! No! Design-by-contract means that it is the application's duty 
>> to make sure that argument values are correct. If the program is 
>> correct, the library can trust that the argument values are correct and 
>> does not need to do checks. This is exactly the same situation that 
>> assertions are for: Double-checking something to catch potential bugs.
>>
>> Exceptions are a very different issue and should never be used for this 
>> purpose.
>>
>> A library interface simply is something different than a user interface.
> 
> Thank you, now I have understood what you mean (I did't understand your first answer to me).
> 
> So you are saying that Contract Programming is not meant to be used to test for wrong inputs coming from the user interface (just like asserts). I think you are right, it is something that needs to be known. I think Michiel Helvensteijn was saying something similar.
> 
> Then the D code in that Wikipedia page (http://en.wikipedia.org/wiki/Class_invariant#D ) may need to be modified again.
> Yet, if you note in the Java code there are extra if tests (that are not present in the Eiffel code):
> 
>     /*@
>     @requires 1<=d && d <=31;
>     @ensures day == d;
>     @*/
>     public void setDay(int d) {
>         if (1 <= d && d <= 31)
>             day = d;
>     }
> 
> Maybe that Java programmer doesn't trust the programmer, and thinks that class can receive code from an user interface. Maybe because the D library uses Contract programming, while the application code does not. What I think you are missing is that there's difference between what's the theoretically correct thing to do, and what's better to do in real code today (for example to avoid certain bugs).
> 
> I am not sure how to write code yet, I'll need practice, and what I have just said can be stupid. But now I understand what's right and why, thanks to this useful discussion. I have never used Contract programming in my past languages, and I have never read books about it, so I didn't know how to use it beside knowing the D syntax to use it. I hope Andrei's book will have some pages about this too, because it's a built-in part of D.
> 
> Bye,
> bearophile