Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!hercule!marcap
From: marcap@hercule.cs.concordia.ca (PAWLOWSKY marc)
Newsgroups: comp.lang.eiffel
Subject: Re: Coping with failure
Message-ID: <1880@clyde.concordia.ca>
Date: 28 Feb 90 19:05:29 GMT
References: <25EB6B0D.2249@maccs.dcss.mcmaster.ca>
Sender: usenet@clyde.concordia.ca
Reply-To: marcap@hercule.CS.Concordia.CA (PAWLOWSKY marc)
Organization: Concordia University, Montreal Quebec
Lines: 32

In article <25EB6B0D.2249@maccs.dcss.mcmaster.ca> howard@maccs.dcss.mcmaster.ca (Howard Betel) writes:
 ...

>Meyer states on page 168 (7.10.3)
>   "Another way to express the same remark is to say that an operation
>    may only succeed or fail; there is no middle ground. 
 ...
>Now I really do understand the importance of this (and the logic) however
>since the assertion defaults are:
>   "NO_ASSERTION_CHECK (Y):
>    PRECONDITIONS (Y): ALL
>    ALL_ASSERTIONS (Y):"
...
>doesn't this allow failures?  If a function is executing and the     
>postconditions are not met, it is possible for a function to complete
>with a failure and the client not know that this occured.
...

You are correct in that a function could fail and not tell its caller.  This
is essentially an eiffeciency issue.  For often the checking is quite time
consuming.  For example I just wrote a class to perform quick_sort.  The
properly check that the procedure has worked it is necessay to check
that the cardinality is still the same, all objects that entered the array
exit the array, the output is sorted.  When an object is "put" into a structure
it should also be checked that the object is in the structure.

While this was fine for debugging, it slows down production programs too much.
For example a program that took over an hour with all assertions took around
10 minutes when the assertions were turned off.

Marc Pawlowsky    Grad Student   Concodia University