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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5c3042563529d4f3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.129.169 with SMTP id nx9mr290527pbb.8.1326413443797; Thu, 12 Jan 2012 16:10:43 -0800 (PST) MIME-Version: 1.0 Path: lh20ni175504pbb.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Data_Error and Enumeration_IO Date: Thu, 12 Jan 2012 18:10:37 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3f3d626a-1b8c-49af-aa85-9e586029a817@z12g2000yqm.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1326413441 4267 69.95.181.76 (13 Jan 2012 00:10:41 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 13 Jan 2012 00:10:41 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-01-12T18:10:37-06:00 List-Id: "John McCormick" wrote in message news:3f3d626a-1b8c-49af-aa85-9e586029a817@z12g2000yqm.googlegroups.com... >I need some assistance in understanding the consumption of input >characters when a Data_Error is raised during the input of an >enumeration value. My experiments show that there is a different >behavior depending on whether the illegal input consists of alphabetic >characters or digits. Jeff and Georg already explained what is going on. But I have to admit I'm surprised that you aren't aware of this, since it has been a problem with Ada.Text_IO since the beginning of time (1980 in Ada's case). My recommendation is always to read the input into a string and then process it there (using the string Gets that the language provides). The reason for this is that it always a better error message in the failure case, because you still have the string in hand. That way, you can avoid a generic message that puzzles the user. [Aside: For some reason, this reminds me of the first C compiler I used, way back at the University of Wisconsin in 1978. It was a PDP-11 compiler for an early version of Unix, and it essentially had two error messages: "lvalue expected" for any compile-time mistake, and "bus error - core dumped" for any run-time mistake. Debugging programs using that compiler were almost completely trial-and-error - you would guess what the error might have been, and try something else to see if it fixed it. The compiler, and the fact that early PC compilers were very much like it, had a lot to do with our creating Janus/Ada a couple of years later. And that is why we always had runtime trace backs and verbose runtime messages from the very beginning...] Randy.