DATA_ERROR exception problem

DATA_ERROR exception problem

[bloom-picayune.mit.edu!snorkelwacker.mit.edu!ira.uka.de!ira.uka.de!math.f]

[Now that we have the umlauts sorted out, the next problem!]

I want to write a compeletly safe input procedure for integers:
I GET an integer, and if DATA_ERROR is raised, I want to loop
around until I get a decent answer. 

My problem is that DATA_ERROR is raised on two different conditions:
an integer being illegal, i.e. out of bounds, or an illegal
character being encountered (such as when I enter "1.0" or "z").
The problem ist that in the former case, the input buffer has been
emptied (all digits read); in the latter, the illegal character
(and all following characters) remain in the input buffer.
How can I differentiate the two cases, so that I can 
GET_LINE (input_garbage, input_garbage_size) and reprompt for input?

On Meridian's PC Ada I get an endless loop if I don't remove the
garbage, and have to enter extra garbage if the problem was a bound
error (!!). Is there any other way to do this besides reading in the
input as a string and patching together an integer myself :-( ?

Stupid me wanted to introduce my beginners to exceptions from the
start - we specified type-safe input, and I expected it to be
relatively straight-forward to implement in Ada. What am I missing?

Thanks for any comments, by mail or by news.
   
-- 
Debora Weber-Wulff                       dww@inf.fu-berlin.de
Institut fuer Informatik                 +49 30 89691 124
Nestorstr. 8-9                           (INCLUDE "standard.disclaimer")
D-W-1000 Berlin 31                       (PRINTN (WITTY-MESSAGE TODAY))

Re: DATA_ERROR exception problem

[David Erickson]

In article <X7D8JTH@math.fu-berlin.de> dww@inf.fu-berlin.de writes:


>I want to write a compeletly safe input procedure for integers:
>I GET an integer, and if DATA_ERROR is raised, I want to loop
>around until I get a decent answer. 


>My problem is that DATA_ERROR is raised on two different conditions:
>an integer being illegal, i.e. out of bounds, or an illegal
>character being encountered (such as when I enter "1.0" or "z").
>The problem ist that in the former case, the input buffer has been
>emptied (all digits read); in the latter, the illegal character
>(and all following characters) remain in the input buffer.


>Is there any other way to do this besides reading in the
>input as a string and patching together an integer myself :-( ?


Well, you could read in the input as a string and use the INTEGER_IO
GET procedure that reads an integer from a string.

Then your exception handling would have to parse the string to
discover the reason.


>Stupid me wanted to introduce my beginners to exceptions from the
>start - we specified type-safe input, and I expected it to be
>relatively straight-forward to implement in Ada. What am I missing?

A beginner's perspective: beginners can break *anything*.

-Dave Erickson

Re: DATA_ERROR exception problem

[munnari.oz.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!cs.adelaide.edu.au!]

In article <X7D8JTH@math.fu-berlin.de>, weberwu@inf.fu-berlin.de (Debora Weber-
Wulff) writes:
|> [Now that we have the umlauts sorted out, the next problem!]
|> 
|> I want to write a compeletly safe input procedure for integers:
|> I GET an integer, and if DATA_ERROR is raised, I want to loop
|> around until I get a decent answer. 
|> 
|> My problem is that DATA_ERROR is raised on two different conditions:
|> an integer being illegal, i.e. out of bounds, or an illegal
|> character being encountered (such as when I enter "1.0" or "z").
|> The problem ist that in the former case, the input buffer has been
|> emptied (all digits read); in the latter, the illegal character
|> (and all following characters) remain in the input buffer.
|> How can I differentiate the two cases, so that I can 
|> GET_LINE (input_garbage, input_garbage_size) and reprompt for input?
|> 

I don't quite understand this. If you want to get an integer, and the input is
"1.0", you should get (at least I get) 1 returned and ".0" left on the input.

However, I think the easiest answer to your question is to read the input
into a string and then do a get from the string. If the whole string is not
used up by the get, you have got some garbage, and you can handle the situation
as you wish.

-- 
#######################################################################
#  Andrew Dunstan                   #   There's nothing good or bad   #
#  Department of Computer Science   #   but thinking makes it so.     #
#  University of Adelaide           #                                 #
#  South Australia                  #          - Shakespeare          #
#  net: andrewd@cs.adelaide.edu.au  #                                 #
#######################################################################

Re: DATA_ERROR exception problem

[Michael Feldman]

In article <X7D8JTH@math.fu-berlin.de> dww@inf.fu-berlin.de writes:
>[Now that we have the umlauts sorted out, the next problem!]
>
>I want to write a compeletly safe input procedure for integers:
>I GET an integer, and if DATA_ERROR is raised, I want to loop
>around until I get a decent answer. 
Very common problem.
>
>My problem is that DATA_ERROR is raised on two different conditions:
>an integer being illegal, i.e. out of bounds, or an illegal
>character being encountered (such as when I enter "1.0" or "z").
>The problem ist that in the former case, the input buffer has been
>emptied (all digits read); in the latter, the illegal character
>(and all following characters) remain in the input buffer.
>How can I differentiate the two cases, so that I can 
>GET_LINE (input_garbage, input_garbage_size) and reprompt for input?
See below.
>
>On Meridian's PC Ada I get an endless loop if I don't remove the
>garbage, and have to enter extra garbage if the problem was a bound
>error (!!). Is there any other way to do this besides reading in the
>input as a string and patching together an integer myself :-( ?
This is not a Meridian problem but the way Text_IO is defined in the LRM.
"The character that causes input to cease remains available for subsequent
input." 

The most "industrial-strength" solution is indeed to read a line into a
string. You don't quite have to "patch together" an integer character-
by-character, because you can always use the Integer_IO Get that Get's
from the string instead of the input buffer. If the operation fails, you
can parse the string a bit to see why it failed. Check your LRM or
Ada book for details on how these Get operations work. Many people
do not realize that they are there!

This is actually quite similar to problems with C input; many C books
recommend using a similar solution technique, making use of sscanf
instead of scanf. So Text_IO doesn't really solve a rather classical
interactive-input problem. On the other hand, at least it's no worse :-)

Are your students first-time programmers - first-year students, whatever -
or just beginners to Ada?

Good luck! Let's hear how you make out!

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: DATA_ERROR exception problem

[Michael Feldman]

In article <EACHUS.92Nov4202155@oddjob.mitre.org> eachus@oddjob.mitre.org (Robe
rt I. Eachus) writes:
>
>   The proper solution is to call Skip_Line after each call to Get,
>unless your user interface specification permits more than one integer
>value per line.  In that case you can either do a Skip_Line on error,
>or read into a String, and parse "by hand" when invalid input is
>encountered.  (I really suggest in any case throwing the queued input
>away when an error is encountered, but especially in an introductory
>class!)
>
Yep. That's how most of us teach it. Interestingly, many students - even
freshmen - want to know if there's a better way, so that input data can
be "batched" on a line. If they've studied strings yet, I tell them about
the "read it into a string" solution, let 'em know it's possible, and
go back to the Skip_Line thing.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------