Good Contract programming idiom?

[Brad Roberts]

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.

Later,
Brad