A very interesting discussion on contract programming — interesting for any language, not only C++.
Comments
On January 2, 2006 10:09 AM, Stefan Tilkov
said:
Can you elaborate — what was the partial understanding? Apart from the ridiculous C++ syntax hoops he has to jump through, I found the article pretty good.
On January 4, 2006 1:16 AM, Doug
said:
Well, there are small to large manglings of DbC theory throughout, but the one that is impossible to overlook is the subhead in huge type, “Contract Violations are Not Exceptional Conditions” (on page 3).
Design by Contract specifies the exact opposite: that exceptions are PRECISELY contract violations. There are no exceptions that are not contract violations, and there are no contract violations that do not (in theory) result in exceptions.
On January 4, 2006 11:23 PM, Stefan Tilkov
said:
I can see both your point and the author’s. If you read what he wrote, he clearly knows that the default and intended way to express contract violations is to throw exceptions. It’s also true, though, that exceptions are used to express non-exceptional conditions in many current environments. (That this is not a good idea is probably true, but irrelevant). He also writes:
In contrast to the activity of exceptions in indicating exceptional runtime conditions or as part of program logic, a contract violation represents the detection of a program state that is explicitly counter to its design. As we’ll see in The Principle Of Irrecoverability (in part 2), upon a contract violation the program is, literally, in an invalid state, and, in principle, there is no further valid action that the program may perform.
I tend to give him the benefit of doubt until I see part 2. I don’t think he’s written anything in that article without thinking about it, though, and I’m reluctant to dismiss everything based on what may be a disagreement over a detail.
On January 5, 2006 7:44 PM, Doug
said:
But it’s not a detail. It’s like a Unified Field Theory that doesn’t include the force of gravity. Design by Contract unifies contracts, inheritance, exceptions, and exception handling into a single theoretical framework based on Hoare logic. It’s a whole heck of a lot more than a bunch of assertions.
If you go back to the abstract… er, summary… of the article, Wilson writes, “there remains equivocation on what to do when contracts are broken. This is Part One of a series that takes a slightly philosophical look at this important issue…”
DbC has no equivocation on what to do when contracts are broken. In DbC, the exception throwing and handling mechanisms are designed expressly to deal with that issue. Bertrand Meyer spends quite some time in “Object Oriented Software Engineering” discussing the various types of contract failures that can arise, the importance of discriminating between recovering from contract failure and retrying, and a number of other topics related to contract failure.
If Wilson had said that he felt there was something lacking in Meyer’s work (like, say, dealing with multithreading), or that he had an interesting alternative, that’d be great. But instead he simply seems to be ignorantly trying to reinvent the wheel. If he can’t be bothered to investigate DbC (there are only a few books to read), I have serious doubts that Wilson has the technical rigor to invent anything of actual value.
On January 5, 2006 8:28 PM, Doug
said:
Er, Meyer’s book is “Object Oriented Software Construction.” Those OO titles all sound the same to me :-)
[sigh] It’s depressing to see people grab onto what they understand and throw away what they don’t understand, then go off and make a new religion from their partial comprehension.
But it’s been done so much in software development, I am not at all surprised to see it happening to Design by Contract.