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: 12 Dec 91 22:06:26 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: Portable End_Error handling desired
Message-ID: <EACHUS.91Dec12140626@Dr_No.mitre.org>
List-Id: <comp.lang.ada>

In article <1991Nov20.011726.4124@milton.u.washington.edu> mfeldman@milton.u.wa
shington.edu (Michael Feldman) writes:

   In article <EACHUS.91Nov19175843@Dr_No.mitre.org> eachus@Dr_No.mitre.org (Ro
bert 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:

-- Loop or recursion is fine, I just happen to find recusrion
-- "simpler."  My main point was that most systems will allow two
-- exceptions while reading one line of input, so you need at least
-- doubly nested exception handlers in the ordinary case.

   (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.)

-- See AI-48.  Actually, on most implementations it is easier to
-- manipulate CURRENT_INPUT, but I think that was what you meant
-- anyway.   In any case, the "real" name of STANDARD_INPUT is
-- implementation dependant, but who cares:

   STD_IO_NAME: constant String := Text_IO.NAME(Text_IO.STANDARD_INPUT);
   MY_FILE: Text_IO.File_Type;

-- Save ahead of time since some implementations raise USE_ERROR for
-- calls of NAME for a closed file.
   ...
   exception
     when TEXT_IO.STATUS_ERROR =>
       Text_IO.Open(My_File,Text_IO.In_File);
       Text_IO.Set_Input(My_File);
   end;

-- In theory USE_ERROR can be raised by the call to OPEN (or for that
-- matter to NAME), but only in cases where opening STANDARD_IN is not
-- permitted by the system.  However if say control-D hangs up
-- the terminal, I don't know what any Ada compiler could do about it.

   (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.

-- This is a silly oversight...was in 1982, is worse now.  Every
-- implementation has a "peek" operation to look at the next character
-- in TEXT_IO, but it is not exported to users.  I usually build one
-- that uses the support packages used by the vendor to write Text_IO.

   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.

-- Here I have to disagree.  Whatever esle you might say about line at
-- a time IO, it certainly is the simplest form of IO to get right.

   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.

-- Oh, maybe we do agree.

   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.

-- I really am impressed if your students can understand the body of
-- TEXT_IO after their first Ada course.  How can I hire some?

   :-) :-) :-) (For the humor impaired.)

-- I have done TEXT_IO implementations in Ada, and although I usually
-- pride myself on the high level of software engineering in my
-- products.  However, there are always places in the body of TEXT_IO
-- where I find I need to insert several paragraphs of comments so
-- that I can remember what I did next time I go back to that line.
-- One of these is correctly setting the point where reading stops in
-- an invalid numeric literal.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...