Re: Assertions (an heretic view)

[gauthier@unilim.fr (Michel Gauthier)]

Many people recently wrote about assertions. I am not really convinced
by the general spirit of the debate. I guess there is a harmful confusion
somewhere. Do not read any more if you think the contrary.

IMHO, it is _essential_ to distinguish :
 - _failures_ : some piece of program does not do what it has been designed
   to do, in an intrinsicly impossible case,
 - _programming errors_ : the programmer did not do what the specification
   required, including failure cases.
Underflowing a stack is (almost always) an error, whereas overflowing a
stack depends on the data and on the environment of each execution, hence
is a failure.

Failures can _always_ be foreseen, and suitable programming can handle
them if appropriate, with exceptions or with any other means.

Errors can _never_ be foreseen.

Coming back to assertions, I guess that they essentially relate to errors,
which they can help detecting. It seems to be a good style not to combine
assertions with failures.

Moreover, I can't agree with the idea that failing an assertion check would 
always result in raising Assert_Error. Failing an assertion check is an effect
of some -possibly incompletely identified- programming error. Different 
possible continuations can be envisaged : raising a well-specified 
exception associated with the case, doing some appropriate thing
(tracing,...), raising some user-defined exception, invoking the debugger,
and possibly others, among which continuing until other failing checks.
   This choice depends on the current status of the project, on the
nature of the checked assertion, on reuse or not, etc. In some cases,
it may depend also on execution options.

From another point of view, assertion-handling components should
be replaceable by others without any other on the program effect than 
early abortion (whether compared with normal end or with abortion).
Do-nothing must be one of the possible assertion-handling components,
to be used for the final program.

This is the spirit of the assertion mechanism that I have coded for
my students (I had some remaining problems with initialisation
of package instances, which seem to be fixed with gnat 3.05).

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------