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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!cs.utexas.edu!uunet!seas.gwu.edu!mfeldman
From: mfeldman@seas.gwu.edu (Michael Feldman)
Newsgroups: comp.lang.ada
Subject: Re: Pre-condition vs. Post-condition
Keywords: pre-condition, post-condition, exception
Message-ID: <2891@sparko.gwu.edu>
Date: 19 Mar 91 19:07:10 GMT
References: <344@platypus.uofs.edu> <2865@sparko.gwu.edu> <97779@tut.cis.ohio-state.edu> <311@nic.cerf.net>
Reply-To: mfeldman@seas.gwu.edu ()
Organization: The George Washington University, Washington D.C.
List-Id: <comp.lang.ada>

In article <311@nic.cerf.net> sss@nic.cerf.net (Marlene M. Eckert) writes:
>How about exceptions should be raised only in _EXCEPTIONAL_ 
>situations?  Reaching the end-of-file or trying to POP off an
>empty stack are NOT exceptional conditions.
>  
Well, this is getting to be an interesting thread on exception-handling
philosophy. I disagree with you. A client of a stack package which 
- due to a logic bug in the client algorithm - tries to pop a stack which
turns out to be empty, is indeed committing an error. IMHO this in indeed
an exceptional situation, and raising Stack_Underflow or whatever is
quite appropriate. The client should use a Stack_Is_Empty boolean
function to test for the empty condition, but s'pose he doesn't?
IMHO _both_ entities should be exported from a stack package.
I agree that a program that tests for the empty condition by trying to
pop and then handling the exception is doing violence to exceptions.

Roughly the same is true for end-file conditions. Text_IO exports a
perfectly good function End_Of_File for this purpose. Nevertheless,
s'pose a client of Text_IO screws up and doesn't test, or tests in
the wrong place? The package should raise End_Error for this unintentional
attempt to read past EOF. As in the stack case, one should NOT write
clients that test for normal EOF by just reading and reading until the
exception is raised. Once again, that's abusive.

Here's a more obvious one:

Given TYPE Days IS (Mon, Tue, Wed, Thu, Fri, Sat, Sun);

we find Tomorrow by writing

   IF Today = Days'Last THEN 
     Tomorrow := Days'First
   ELSE
     Tomorrow := Days'Succ(Today);
   END IF;

NOT

   BEGIN
     Tomorrow := Days'Succ(Today);
   EXCEPTION
     WHEN Constraint_Error => 
       Tomorrow := Days'First;
   END;

Some bit-fiddlers have argued that the latter is slightly more efficient,
but I still think it's abusive. Monday follows Sunday EVERY WEEK. The
only thing surprising about it is that Ada doesn't allow cyclic types!

Mike Feldman