Wed, 03 Mar 2010 14:09:59 -0800, Brad Roberts wrote: > On Wed, 3 Mar 2010, Norbert Nemec wrote: > >> 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 > > There's an important point that's been left out of this conversation so > far (unless I missed it): > > Asserts in the body of a method have no impact on overridden > implementations in subclasses, but in/out contracts do. So there's a > distinct value in using in/out for non-final methods.
The fact is also mentioned here: http://en.wikipedia.org/wiki/Design_by_contract "Subclasses in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them). These rules approximate behavioral subtyping."
