Exception problem

Exception problem

[Larry Coon]

Ada beginner here...

The intent of the following code is to loop until valid input is 
provided:

declare
   X: Positive;
   package Int_IO is new Integer_IO (Integer);
   use Int_IO;
begin
   loop
      begin
         Put ("Enter a positive number: ");
         Get (X);
         exit; -- No exception, so input was valid.
      exception
         when Constraint_Error =>
            Put_Line ("Entry must be positive.  Try again.");
         when Data_Error =>
            Put_Line ("Entry must be a number.  Try again.");
      end;
   end loop;
   -- Procesing for X....
end;

The idea is that if input is not valid an exception will be thrown, the 
appropriate message will be displayed, and the code will loop back to 
the prompt.  If no exception is thrown the input is valid, and the exit 
statement take the program out of the loop.

This code handles non-positive numeric input (eg: 0 or -3) correctly.  
But when I give it non-numeric input (eg: C), it displays the "Entry 
must be a number.  Try again" message repeatedly and never stops for 
input again.

Compiler is Thomson Academic ObjectAda V7.0.171 in Win 95.

I'd appreciate any insight.

Larry Coon
University of California
larry@fs2.assist.uci.edu

Re: Exception problem

[Michael Feldman]

In article <330A0D25.313@fs2.assist.uci.edu>,
Larry Coon  <larry@fs2.assist.uci.edu> wrote:

>   loop
>      begin
>         Put ("Enter a positive number: ");
>         Get (X);
>         exit; -- No exception, so input was valid.
>      exception
>         when Constraint_Error =>
>            Put_Line ("Entry must be positive.  Try again.");
>         when Data_Error =>
>            Put_Line ("Entry must be a number.  Try again.");
You need 
             Skip_line;
here, which advances the input beyond the line terminator.
The problem is that if your first character is non-numeric,
the exception is read and the character is left in the buffer.
This is correct RM behavior; numeric input ceases when a character
is encountered that can't be part of a numeric token. It stays in
the input buffer because it might have been intended to be picked
up on the next read.

>      end;
>   end loop;

>The idea is that if input is not valid an exception will be thrown, the 

in Ada jargon, exceptions are "raised" and "handled".

>appropriate message will be displayed, and the code will loop back to 
>the prompt.  If no exception is thrown the input is valid, and the exit 
>statement take the program out of the loop.

Right - a standard Ada "robust input loop".

>This code handles non-positive numeric input (eg: 0 or -3) correctly.  
>But when I give it non-numeric input (eg: C), it displays the "Entry 
>must be a number.  Try again" message repeatedly and never stops for 
>input again.

Well, because that character is left in the buffer and never read,
your program loops and keeps trying to read it again and again.

This is a very common situation for beginners. I think it's discussed
in the programmer FAQ accessible from www.adahome.com. It's also
covered in some detail in that textbook by Feldman/Koffman, in Chap. 6.

Since it's quite proper RM behavior, you'll find this to be compiler-
independent.

I hope this helps.

Mike Feldman

Re: Exception problem

[Joerg Rodemann]

Larry Coon (larry@fs2.assist.uci.edu) wrote:
>       begin
>          Put ("Enter a positive number: ");
>          Get (X);
>          exit; -- No exception, so input was valid.
>       exception
>          when Constraint_Error =>
>             Put_Line ("Entry must be positive.  Try again.");
>          when Data_Error =>
>             Put_Line ("Entry must be a number.  Try again.");
>       end;

> This code handles non-positive numeric input (eg: 0 or -3) correctly.  
> But when I give it non-numeric input (eg: C), it displays the "Entry 
> must be a number.  Try again" message repeatedly and never stops for 
> input again.

It seems to me your problem is that Get checks for validity of the data by 
raises the Data_Error exception already before any characters are removed 
from the input buffer. Therefore the token leading to Data_Error will be 
processed during the next Get in the same way as before. 

Although I do not have the ARM at hand I think a Flush(Standard_Input) might 
solve this situation.

Hope this helps

Greetings

George

--
Joerg 'George' Rodemann                      Erhard-Groezinger-Strasse 82
Department of Physics                                   D-89134 Blaustein
University of Ulm                                      Tel. (0731) 553319
e-mail:                                    rodemann@mathematik.uni-ulm.de

Re: Exception problem

[David C. Hoos, Sr.]

The problem is that when Text_IO.Data_Error is raised in this circumstance,
the pointer in the input stream is backed up to where it was before the
Int_IO.Get was called.  Therefore, if you want to skip over this
non-numeric data in the input stream, you should call Text_IO.Skip_Line
just after the line:
Put_Line ("Entry must be a number.  Try again.");

Incidentally, Ada is much more civilized than C++.  We don't "throw"
things.  Exceptions are simply "raised."

One other point about your code.  Instantiations of generics (e.g.,
Text_IO.Integer_IO) for commonly used types are better placed at the
Library level, so all parts of your program can use the same instantiation.
 Depending on the compiler/binder/linker used, code for multiple identical
instantations may or may not share the code.
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Larry Coon <larry@fs2.assist.uci.edu> wrote in article
<330A0D25.313@fs2.assist.uci.edu>...
> Ada beginner here...
> 
> The intent of the following code is to loop until valid input is 
> provided:
> 

Re: Exception problem

[Mats Weber]

> Although I do not have the ARM at hand I think a Flush(Standard_Input) might
> solve this situation.

No, it won't. Flush has no effect on the file's content or state as
visible by the program. If you don't know the exact effect of Flush,
it's better to stay away from it :-)

Re: Exception problem

[Robert Dewar]

David said

<<The problem is that when Text_IO.Data_Error is raised in this circumstance,
the pointer in the input stream is backed up to where it was before the
Int_IO.Get was called>>

A clearer and more accurate (though equivalent) is that the pointer in the
input stream is never moved past the bad character in the first place, so
no backing up is needed, i.e. the pointer is moved to the first non-blank,
and then is only moved further if valid input is found.

Re: Exception problem

[Larry Coon]

David C. Hoos, Sr. wrote:
> 
> The problem is that when Text_IO.Data_Error is raised in this circumstance,
> the pointer in the input stream is backed up to where it was before the
> Int_IO.Get was called.  Therefore, if you want to skip over this
> non-numeric data in the input stream, you should call Text_IO.Skip_Line
> just after the line:
> Put_Line ("Entry must be a number.  Try again.");

Thanks.  Michael Feldman also pointed this out, and it worked like a
charm.
 
> Incidentally, Ada is much more civilized than C++.  We don't "throw"
> things.  Exceptions are simply "raised."

And apparently in Ada you're more sure of yourselves, because you don't
"try" things either!  ;-)

> One other point about your code.  Instantiations of generics (e.g.,
> Text_IO.Integer_IO) for commonly used types are better placed at the
> Library level, so all parts of your program can use the same instantiation.
>  Depending on the compiler/binder/linker used, code for multiple identical
> instantations may or may not share the code.

Oh, it was in the real code, but this was a contrived example to
demonstrate the problem.

Thanks for your response.

Larry Coon
University of California
larry@fs2.assist.uci.edu

Re: Exception problem

[Keith Allan Shillington]

Classic error.  If you input a non-numeric character, it gets "stuck" in the
input buffer and never processed.  To throw away unwanted characters in the
input buffer, the simplest thing to do is add a call to Text_IO.Skip_Line in
each of your handlers.

Larry Coon <larry@fs2.assist.uci.edu> wrote...
> 
> declare
>    X: Positive;
>    package Int_IO is new Integer_IO (Integer);
>    use Int_IO;
> begin
>    loop
>       begin
>          Put ("Enter a positive number: ");
>          Get (X);
>          exit; -- No exception, so input was valid.
>       exception
>          when Constraint_Error =>
>             Put_Line ("Entry must be positive.  Try again.");
              Skip_Line;
>          when Data_Error =>
>             Put_Line ("Entry must be a number.  Try again.");
              Skip_Line;
>       end;
>    end loop;  ...

Re: Exception problem

[Larry Coon]

Michael Feldman wrote:

> You need
>              Skip_line;
> here, which advances the input beyond the line terminator.
> The problem is that if your first character is non-numeric,
> the exception is read and the character is left in the buffer.
> This is correct RM behavior; numeric input ceases when a character
> is encountered that can't be part of a numeric token. It stays in
> the input buffer because it might have been intended to be picked
> up on the next read.

Ahh, that's it!  I figured it probably wasn't advancing past the
character, and I guess that it makes sense that the Get call would
continue to try to use the character if it remains in the buffer.

> in Ada jargon, exceptions are "raised" and "handled".

Can you tell what language I use most? ;-)

Larry Coon
University of California
larry@fs2.assist.uci.edu

Re: Exception problem

[Arthur Evans Jr]

Larry Coon <larry@fs2.assist.uci.edu> wrote:

> This code handles non-positive numeric input (eg: 0 or -3) correctly.  
> But when I give it non-numeric input (eg: C), it displays the "Entry 
> must be a number.  Try again" message repeatedly and never stops for 
> input again.

When Get(X) notes that the first character ('C' in your case) cannot be
valid, it immediately raises the exception without reading anything from
the input stream.  So, the offending character is still there on the
next try.  Add a call to Skip_Line.

Art Evans

Arthur Evans Jr, PhD
Ada Consulting
evans@evans.pgh.pa.us

Re: Exception problem

[Larry Coon]

Arthur Evans Jr wrote:

> . . . Add a call to Skip_Line.

That did the trick, thanks.

By the way, that brings up another question....that of when it's
appropriate to use exceptions.  In C++, for example, you wouldn't want
to throw an exception because your number should be positive and you got
a negative.  In C++, you're using an int to represent this number, and
for an int to be -3 is not an exceptional condition.  However, in Ada
subtypes and derived types allow you to declare integers for which -3
truly is an exceptional condition, making it very appropriate to raise
(see, I even got the terminology right!) an exception.

Writing that code almost made me feel guilty for using exceptions the
wrong way, and I wanted to make sure I'm thinking about them in the
right way in Ada.

Larry Coon
University of California
larry@fs2.assist.uci.edu

Re: Exception problem

[Larry Kilgallen]

In article <3311BFC4.7576@fs2.assist.uci.edu>, Larry Coon <larry@fs2.assist.uci.edu> writes:

> By the way, that brings up another question....that of when it's
> appropriate to use exceptions.  In C++, for example, you wouldn't want
> to throw an exception because your number should be positive and you got
> a negative.  In C++, you're using an int to represent this number, and
> for an int to be -3 is not an exceptional condition.  However, in Ada
> subtypes and derived types allow you to declare integers for which -3
> truly is an exceptional condition, making it very appropriate to raise
> (see, I even got the terminology right!) an exception.
> 
> Writing that code almost made me feel guilty for using exceptions the
> wrong way, and I wanted to make sure I'm thinking about them in the
> right way in Ada.

Implementations are likely to use hardware exception mechanisms and
other non-speed-optimized techniques to implement something called
an "exception" in any language.  Thus you should not count on using
exceptions as a "normal" part of processing which is supposed to run
efficiently.

In this particular case, the decision should probably based not on
the fact that typing wrong characters may or may not be "normal" for
your user population, but rather on the fact that anything taking
keyboard input from humans has no hope of running fast enough to
waste many cycles anyway.  Considering that you may type out an
error message or something similar (I forget the original code)
in the wrong keystroke case, the overhead of depending on exceptions
might be lost in the noise of other activity anyway.

Besides, somebody ought to be testing the exception handling of
compilers on a regular basis -- I nominate you :-)

Larry Kilgallen

Re: Exception problem

[Larry Coon]

Larry Kilgallen wrote:
> 
> In article <3311BFC4.7576@fs2.assist.uci.edu>, Larry Coon <larry@fs2.assist.uci.edu> writes:
> 
> > By the way, that brings up another question....that of when it's
> > appropriate to use exceptions.  In C++, for example, you wouldn't want
> > to throw an exception because your number should be positive and you got
> > a negative.  In C++, you're using an int to represent this number, and
> > for an int to be -3 is not an exceptional condition.  However, in Ada
> > subtypes and derived types allow you to declare integers for which -3
> > truly is an exceptional condition, making it very appropriate to raise
> > (see, I even got the terminology right!) an exception.
> >
> > Writing that code almost made me feel guilty for using exceptions the
> > wrong way, and I wanted to make sure I'm thinking about them in the
> > right way in Ada.
> 
> Implementations are likely to use hardware exception mechanisms and
> other non-speed-optimized techniques to implement something called
> an "exception" in any language.  Thus you should not count on using
> exceptions as a "normal" part of processing which is supposed to run
> efficiently.

My concern is not so much related to performance as it is to the
general  axiom (at least in C++) that exception handling is meant for
truly exceptional events, and that invalid input just doesn't qualify. 
The general rule in C++ is that exception handling shouldn't be used for
input validation.

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?

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

Larry Coon
University of California
larry@fs2.assist.uci.edu

Re: Exception problem

[Fergus Henderson]

Larry Coon <larry@fs2.assist.uci.edu> writes:

>My concern is not so much related to performance as it is to the
>general  axiom (at least in C++) that exception handling is meant for
>truly exceptional events, and that invalid input just doesn't qualify. 
>The general rule in C++ is that exception handling shouldn't be used for
>input validation.

I don't think this "axiom" is universally accepted in the C++ community.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Exception problem

[Do-While Jones]

In article <3311BFC4.7576@fs2.assist.uci.edu> larry@fs2.assist.uci.edu writes:
>Arthur Evans Jr wrote:
>
>> . . . Add a call to Skip_Line.
>
>That did the trick, thanks.
>
>By the way, that brings up another question....that of when it's
>appropriate to use exceptions.  In C++, for example, you wouldn't want
>to throw an exception because your number should be positive and you got
>a negative.  In C++, you're using an int to represent this number, and
>for an int to be -3 is not an exceptional condition.  However, in Ada
>subtypes and derived types allow you to declare integers for which -3
>truly is an exceptional condition, making it very appropriate to raise
>(see, I even got the terminology right!) an exception.
>
>Writing that code almost made me feel guilty for using exceptions the
>wrong way, and I wanted to make sure I'm thinking about them in the
>right way in Ada.

I would have written the program almost exactly the way you did.  The 
only difference is that I would have used "Get_Line(TEXT, LENGTH);" 
instead of Get.  That would have eliminated the need for the Skip_Line.

After obtaining the text from the user, I would have used the 'VALUE 
attribute to convert TEXT(1 .. LENGTH) to the integer type, if possible.  
The 'VALUE attribute will raise an exception if the text string isn't an 
integer, so you would have no choice but to use an exception handler.

If the 'VALUE attribute raises CONSTRAINT_ERROR when trying to convert 
the string to an integer, I normally send an error message that shows the 
incorrect input.  For example,

Put_Line(TEXT(1 .. LENGTH) & " is not an integer."); 

Then I loop back and ask for the input again, as you did.

Using Get_Line to get the entire text string also gives me the opportunity
to make a remarkably smart user interface.  Suppose some smart-aleck user
enters "XXV" or "twenty-five".  I could write an exception handler that
tries to interpret the string when the 'VALUE attribute fails.  The
handler could be written to recognize Roman numerals and number names.  If
it successfully interprets the value it could respond,

Put_Line("Why didn't you just enter" & integer'IMAGE(I) & "?");
Put_Line("Don't answer that.  I'm just thinking out loud.")
Put_Line("I will now process your data.");

(Management would probably not allow me to leave that in the final 
product, but sometimes I can sneak those things through.)

>Larry Coon
>University of California
>larry@fs2.assist.uci.edu

Do-While Jones




-- 
            +--------------------------------+
            |    Know                 Ada    |
            |        [Ada's Portrait]        |
            |    Will              Travel    |
            | wire do_while@ridgecrest.ca.us |
            +--------------------------------+

Re: Exception problem

[Robert I. Eachus]

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

Re: Exception problem

[Robert Dewar]

John Volan said

<<    Get (Text, Length);
    Get (From => Text (1 .. Length), -- eats any leading whitespace
         Item => Your_Integer,
         Last => Next); -- stops at the end of the integer literal,
                        -- before any trailing whitespace (or indeed,
                        -- any trailing anything
    -- optionally, if you want to do something with the rest of the input line,
    -- you can do:>>

Beware of this approach, it is a little too forgiving. For example, if
you read in 16.23 as an integer, it will work fine, reading 16, and stopping
at the period. You can of course check this, but I have seen several bug
reports from people who get trapped by this and expect data error, and
do not get it!

Re: Exception problem

[John Volan]

> I would have written the program almost exactly the way you did.  The 
> only difference is that I would have used "Get_Line(TEXT, LENGTH);" 
> instead of Get.  That would have eliminated the need for the Skip_Line.
> 
> After obtaining the text from the user, I would have used the 'VALUE 
> attribute to convert TEXT(1 .. LENGTH) to the integer type, if possible.  
> The 'VALUE attribute will raise an exception if the text string isn't an 
> integer, so you would have no choice but to use an exception handler.

The disadvantage in using 'Value is that it is not very forgiving if the
input is not *exactly* an integer literal, i.e., if there is white space
before and/or after the integer literal within the input string. An
alternative method is to go ahead and read the input line into a string
buffer, but then use a Get procedure from an instantiation of
Ada.Text_IO.Integer_IO:

    Get (Text, Length);
    Get (From => Text (1 .. Length), -- eats any leading whitespace
         Item => Your_Integer,
         Last => Next); -- stops at the end of the integer literal,
                        -- before any trailing whitespace (or indeed,
                        -- any trailing anything
    -- optionally, if you want to do something with the rest of the input line,
    -- you can do:
    Next := Next + 1;
    -- and then do further processing on Text (Next .. Length)
> I would have written the program almost exactly the way you did.  The 
> only difference is that I would have used "Get_Line(TEXT, LENGTH);" 
> instead of Get.  That would have eliminated the need for the Skip_Line.
> 
> After obtaining the text from the user, I would have used the 'VALUE 
> attribute to convert TEXT(1 .. LENGTH) to the integer type, if possible.  
> The 'VALUE attribute will raise an exception if the text string isn't an 
> integer, so you would have no choice but to use an exception handler.

The disadvantage in using 'Value is that it is not very forgiving if the
input is not *exactly* an integer literal, i.e., if there is white space
before and/or after the integer literal within the input string. An
alternative method is to go ahead and read the input line into a string
buffer, but then use a Get procedure from an instantiation of
Ada.Text_IO.Integer_IO:

    Get (Text, Length);
    Get (From => Text (1 .. Length), -- eats any leading whitespace
         Item => Your_Integer,
         Last => Next); -- stops at the end of the integer literal,
                        -- before any trailing whitespace (or indeed,
                        -- any trailing anything
    -- optionally, if you want to do something with the rest of the input line,
    -- you can do:
    Next := Next + 1;
    -- and then do further processing on Text (Next .. Length)

----------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan", Home_Email => "johnvolan@macconnect.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "No one ever defined these opinions, so using them" 
     & "is totally erroneous...or is that a bounded error now? :-) ");
----------------------------------------------------------------------

Re: Exception problem

[Keith Thompson]

In <JohnVolan-0903971008050001@accs-as34-dp04.snfc.grid.net> JohnVolan@macconnect.com (John Volan) writes:
[...]
> The disadvantage in using 'Value is that it is not very forgiving if the
> input is not *exactly* an integer literal, i.e., if there is white space
> before and/or after the integer literal within the input string.

No, 'Value ignores leading and trailing spaces.  See RM95-3.5(54).

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
5040 Shoreham Place, San Diego, CA, USA, 92122-5989
"Humor is such a subjective thing." -- Cartagia