From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2e71cf22768a124d X-Google-Attributes: gid103376,public From: gauthier@unilim.fr (Michel Gauthier) Subject: Re: Assertions (an heretic view) Date: 1996/06/28 Message-ID: #1/1 X-Deja-AN: 162544498 references: organization: Universite de Limoges newsgroups: comp.lang.ada Date: 1996-06-28T00:00:00+00:00 List-Id: 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 ---------- ---------- ---------- ----------