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