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,eee47022b0e39dbb
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Exception problem
Date: 1997/02/25
Message-ID: <EACHUS.97Feb25112121@spectre.mitre.org>#1/1
X-Deja-AN: 221345552
References: <330A0D25.313@fs2.assist.uci.edu>
 <evans-2202972108360001@ppp1.s8.pgh.net>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1997-02-25T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <3311FD32.2DDA@fs2.assist.uci.edu> Larry Coon <larry@fs2.assist.uci.edu> writes:

  > However, given the more powerful type definition capabilities of Ada,
  > invalid input can create exceptional conditions that wouldn't be
  > exceptional in C++.  So I guess my question is, does that make it okay
  > to use exception handling for input validation in Ada?

  There are cases where it is not only acceptable, it is the only way
to deal with bad input.  For example, if you are reading a series of
records in a specified format and encounter the end of the file in the
middle of a record it is hard to deal with the situation in any other
way.  Of course the loop that reads the records should check for end
of file after reading each record since you know that eventually you
will run out of data.

  > Or, in cases such as keyboard input, should I go on the premise
  > that the user is inputing using a keyboard, keyboards produce
  > characters, and character input is what should be expected.
  > Therefore, the correct thing to do is to accept character input,
  > validate it, and then if it's okay convert it to the appropriate
  > type.  Granted, doing it the first way is a lot easier....

   There are cases where if you don't validate the input, your program
will be erroneous.  Ada 95 added X'Valid to deal with such cases.
Whether 'Valid needs to be wrapped in an exception handler depends on
program design and the data being accessed, but in general you don't
worry about whether the 'Valid check fails or some exception is
raised:

    function Read_Next_Value return My_Type is
      Temp: My_Type;
    begin
      My_Type_IO.Get(Foo, Temp);
      if My_Type'Valid(Temp) 
      then return Temp;
      else raise Data_Error;
      end if;
    exception
      when others => raise Data_Error;
    end Read_Next_Value;

    (For those purists among you, assume that this is reading from a
data file written by some other version of the program.  Also note the
check for end of file, if needed, is assumed to be at an outer level.)

    Why map everything to Data_Error?  Why not?  During debugging you
are going to care why the data can't be read, but in most programs, if
the inital input data is bad, you can't do much to recover.  For
example you might be reading a series of entries from a configuration
file.  The error message at the next level up might specify where the
error occured:

       "Error in config file at line XXX position YY."

    But in some cases that is about all you can do.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...