* Exception problem @ 1997-02-18 0:00 Larry Coon 1997-02-18 0:00 ` Michael Feldman ` (4 more replies) 0 siblings, 5 replies; 19+ messages in thread From: Larry Coon @ 1997-02-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-18 0:00 Exception problem Larry Coon @ 1997-02-18 0:00 ` Michael Feldman 1997-02-19 0:00 ` Larry Coon 1997-02-19 0:00 ` David C. Hoos, Sr. ` (3 subsequent siblings) 4 siblings, 1 reply; 19+ messages in thread From: Michael Feldman @ 1997-02-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-18 0:00 ` Michael Feldman @ 1997-02-19 0:00 ` Larry Coon 0 siblings, 0 replies; 19+ messages in thread From: Larry Coon @ 1997-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-18 0:00 Exception problem Larry Coon 1997-02-18 0:00 ` Michael Feldman @ 1997-02-19 0:00 ` David C. Hoos, Sr. 1997-02-19 0:00 ` Robert Dewar 1997-02-19 0:00 ` Larry Coon 1997-02-19 0:00 ` Joerg Rodemann ` (2 subsequent siblings) 4 siblings, 2 replies; 19+ messages in thread From: David C. Hoos, Sr. @ 1997-02-19 0:00 UTC (permalink / raw) 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: > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-19 0:00 ` David C. Hoos, Sr. @ 1997-02-19 0:00 ` Robert Dewar 1997-02-19 0:00 ` Larry Coon 1 sibling, 0 replies; 19+ messages in thread From: Robert Dewar @ 1997-02-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-19 0:00 ` David C. Hoos, Sr. 1997-02-19 0:00 ` Robert Dewar @ 1997-02-19 0:00 ` Larry Coon 1 sibling, 0 replies; 19+ messages in thread From: Larry Coon @ 1997-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-18 0:00 Exception problem Larry Coon 1997-02-18 0:00 ` Michael Feldman 1997-02-19 0:00 ` David C. Hoos, Sr. @ 1997-02-19 0:00 ` Joerg Rodemann 1997-02-19 0:00 ` Mats Weber 1997-02-19 0:00 ` Keith Allan Shillington 1997-02-22 0:00 ` Arthur Evans Jr 4 siblings, 1 reply; 19+ messages in thread From: Joerg Rodemann @ 1997-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-19 0:00 ` Joerg Rodemann @ 1997-02-19 0:00 ` Mats Weber 0 siblings, 0 replies; 19+ messages in thread From: Mats Weber @ 1997-02-19 0:00 UTC (permalink / raw) > 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 :-) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-18 0:00 Exception problem Larry Coon ` (2 preceding siblings ...) 1997-02-19 0:00 ` Joerg Rodemann @ 1997-02-19 0:00 ` Keith Allan Shillington 1997-02-22 0:00 ` Arthur Evans Jr 4 siblings, 0 replies; 19+ messages in thread From: Keith Allan Shillington @ 1997-02-19 0:00 UTC (permalink / raw) 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; ... ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-18 0:00 Exception problem Larry Coon ` (3 preceding siblings ...) 1997-02-19 0:00 ` Keith Allan Shillington @ 1997-02-22 0:00 ` Arthur Evans Jr 1997-02-24 0:00 ` Larry Coon 1997-02-25 0:00 ` Robert I. Eachus 4 siblings, 2 replies; 19+ messages in thread From: Arthur Evans Jr @ 1997-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-22 0:00 ` Arthur Evans Jr @ 1997-02-24 0:00 ` Larry Coon 1997-02-24 0:00 ` Larry Kilgallen 1997-02-25 0:00 ` Do-While Jones 1997-02-25 0:00 ` Robert I. Eachus 1 sibling, 2 replies; 19+ messages in thread From: Larry Coon @ 1997-02-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-24 0:00 ` Larry Coon @ 1997-02-24 0:00 ` Larry Kilgallen 1997-02-24 0:00 ` Larry Coon 1997-02-25 0:00 ` Do-While Jones 1 sibling, 1 reply; 19+ messages in thread From: Larry Kilgallen @ 1997-02-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-24 0:00 ` Larry Kilgallen @ 1997-02-24 0:00 ` Larry Coon 1997-02-25 0:00 ` Fergus Henderson 0 siblings, 1 reply; 19+ messages in thread From: Larry Coon @ 1997-02-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-24 0:00 ` Larry Coon @ 1997-02-25 0:00 ` Fergus Henderson 0 siblings, 0 replies; 19+ messages in thread From: Fergus Henderson @ 1997-02-25 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-24 0:00 ` Larry Coon 1997-02-24 0:00 ` Larry Kilgallen @ 1997-02-25 0:00 ` Do-While Jones 1997-03-09 0:00 ` John Volan 1 sibling, 1 reply; 19+ messages in thread From: Do-While Jones @ 1997-02-25 0:00 UTC (permalink / raw) 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 | +--------------------------------+ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-25 0:00 ` Do-While Jones @ 1997-03-09 0:00 ` John Volan 1997-03-09 0:00 ` Robert Dewar 1997-03-12 0:00 ` Keith Thompson 0 siblings, 2 replies; 19+ messages in thread From: John Volan @ 1997-03-09 0:00 UTC (permalink / raw) > 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? :-) "); ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-03-09 0:00 ` John Volan @ 1997-03-09 0:00 ` Robert Dewar 1997-03-12 0:00 ` Keith Thompson 1 sibling, 0 replies; 19+ messages in thread From: Robert Dewar @ 1997-03-09 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-03-09 0:00 ` John Volan 1997-03-09 0:00 ` Robert Dewar @ 1997-03-12 0:00 ` Keith Thompson 1 sibling, 0 replies; 19+ messages in thread From: Keith Thompson @ 1997-03-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exception problem 1997-02-22 0:00 ` Arthur Evans Jr 1997-02-24 0:00 ` Larry Coon @ 1997-02-25 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 19+ messages in thread From: Robert I. Eachus @ 1997-02-25 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~1997-03-12 0:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-02-18 0:00 Exception problem Larry Coon 1997-02-18 0:00 ` Michael Feldman 1997-02-19 0:00 ` Larry Coon 1997-02-19 0:00 ` David C. Hoos, Sr. 1997-02-19 0:00 ` Robert Dewar 1997-02-19 0:00 ` Larry Coon 1997-02-19 0:00 ` Joerg Rodemann 1997-02-19 0:00 ` Mats Weber 1997-02-19 0:00 ` Keith Allan Shillington 1997-02-22 0:00 ` Arthur Evans Jr 1997-02-24 0:00 ` Larry Coon 1997-02-24 0:00 ` Larry Kilgallen 1997-02-24 0:00 ` Larry Coon 1997-02-25 0:00 ` Fergus Henderson 1997-02-25 0:00 ` Do-While Jones 1997-03-09 0:00 ` John Volan 1997-03-09 0:00 ` Robert Dewar 1997-03-12 0:00 ` Keith Thompson 1997-02-25 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox