The Nuclear Reactor and the Deep Space Probe
A very interesting discussion on contract programming — interesting for any language, not only C++.
This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.
[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.
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.
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.
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:
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.
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.
Er, Meyer’s book is “Object Oriented Software Construction.” Those OO titles all sound the same to me :-)