Reusability and assertions (Was: Assertion Error)

[gauthier@alphainfo.unilim.fr (Michel Gauthier)]

In article <6b64u1$cjd$1@goanna.cs.rmit.edu.au>, Dale Stanbrough,
<dale@goanna.cs.rmit.edu.au>, replying to :

>>  "Got a problem:
>>     When compiling code being ported from another platform, we get an
>>   "assertion error".   We are using the Rational VADS system on Solaris.  
>>  Can someone explain to me what the meaning is and what we might  possibly do
>>  to remedy the problem?"

 wrote:

>>  You make lots of assertions about programs when you write them. Most are
>>  in the form of type declarations ('this variable is used to hold integer
>>  values'). Some are about the valid range of values it may hold ('this
>>  variable can only have values b/w 1 and 10'). Other things you may
>>  want to assert may not be directly expressed using language features
>>  but can be in the form of a boolean expression (e.g. 'this pointer is now
>>  non null'). Somewhere, some clever person has put an assertion in your
>>  code, and now some fundamental assumption that they made (either about
>>  the environment, or how the program is to work) has been broken, and
>>  your software is kindly telling you about it.

I can't consider raising Assertion_Error in a reusable component to be
clever programming.

Any bad functioning shall be specified and raised in the form of an exception.
The spirit is "the service coundn't be achieved", whichever the reason but
ordinarily some intrinsicly impossible case, independently of the
programmer's work.

Assertion checking shall be an additional process that is inserted to detect 
programming errors, events that are essentially different from "the service
coundn't be achieved".

In this sense, assertion checking should not report any other information
than "a priori, you have no responsibility on the crash, contact the
maintenance". I guess it is better to trace assertion failures than to make 
the first occurrence raise anything.

Of course, this applies to reusable parts or programs, not to
project-specific ones.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone + 33 5 55 43 69 73
fax +33 5 55 43 69 77
----------          ----------          ----------          ----------
Les concepts, c'est comme les chats : s'ils se rencontrent, ils se battent.
Concepts are like cats : if they meet, they fight.
----------          ----------          ----------          ----------