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
