From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 20 Nov 91 01:17:26 GMT
From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!samsung!caen!usenet.coe.montana.
edu!ogicse!henson!milton!mfeldman@ames.arc.nasa.gov  (Michael Feldman)
Subject: Re: Portable End_Error handling desired
Message-ID: <1991Nov20.011726.4124@milton.u.washington.edu>
List-Id: <comp.lang.ada>

In article <EACHUS.91Nov19175843@Dr_No.mitre.org> eachus@Dr_No.mitre.org (Rober
t I. Eachus) writes:
>
>     If you are trying to write "bulletproof" code, you need to have a
>procedure that recursively calls itself in its exception handler.  It
>should also be nested in an outer handler, and keep track of depth of
>nesting so that it can give up gracefully before running off the end
>of the stack (or causing him to reboot the machine).
>
Hmmm. I don't really think recursion is necessary to guard against
strange input from the keyboard; a loop will do. The problem I have
is twofold:

(1) keep reading from the keyboard even if EOF (ctrl-Z or ctrl-D)
is pressed. Since EOF means the file is now "empty", the problem is
to recover Standard_Input after fielding the exception. I do NOT
think there is a portable solution to this, because Text_IO doesn't
allow Standard_Input to be closed and then re-opened, at least not
portably. (Doug Bryan agrees.)

(2) raise and handle an exception if e.g. a float literal is entered
when an integer one was expected. If the integral part of the float
literal happens to be in range, it will be read as valid, raising no
exception, and leaving the decimal point and the fractional part in the 
buffer. 

Here there is a portable solution, for example reading a line into a 
string and then parsing it more-or-less manually. This is not suitable for
the 1st-quarter students to whom I am trying to teach exception handling.

Interactive, human-typed input is the nastiest thing to get right,
whatever the language. It's a fun exercise to see in which ways Ada
makes it marginally easier or harder, but it's messy no matter what.
This is, I think, one reason why some Ada teachers prefer to hide all the
messiness in their own package, keeping the students away from the
details. This is a valid approach, but I prefer not to send the students
off to use packages whose bodies they won't understand before the course
is over. Better to have them learn that the world is messy.

Mike