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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,cfb2002511b830ab X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.205.133.193 with SMTP id hz1mr565766bkc.7.1322340464721; Sat, 26 Nov 2011 12:47:44 -0800 (PST) Path: dq5ni54677bkb.0!nntp.google.com!news1.google.com!goblin3!goblin1!goblin.stu.neva.ru!news.tornevall.net!.POSTED!not-for-mail From: Jeffrey Carter Newsgroups: comp.lang.ada Subject: Re: Starter project: getopt_long in Ada Date: Sat, 26 Nov 2011 13:47:42 -0700 Organization: TornevallNET - http://news.tornevall.net Message-ID: References: <4ecfc4c4$0$6579$9b4e6d93@newsspool3.arcor-online.net> NNTP-Posting-Host: 567453fc1260af77bb898140d5bfd967 Mime-Version: 1.0 X-Trace: 23f258620b533cad1438d8ad8e663ce1 X-Complaints-To: abuse@tornevall.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 X-Complaints-Language: Spoken language is english or swedish - NOT ITALIAN, FRENCH, GERMAN OR ANY OTHER LANGUAGE! In-Reply-To: X-UserIDNumber: 1738 X-Validate-Post: http://news.tornevall.net/validate.php?trace=23f258620b533cad1438d8ad8e663ce1 X-Complaints-Italiano: Non abbiamo padronanza della lingua italiana - se mandate una email scrivete solo in Inglese, grazie X-Posting-User: 0243687135df8c4b260dd4a9a93c79bd Xref: news1.google.com comp.lang.ada:19180 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2011-11-26T13:47:42-07:00 List-Id: On 11/26/2011 11:13 AM, Natasha Kerensikova wrote: > > In most use cases I can imagine, an application encountering an error in > argument parsing will just print a "usage" text and exit with an error > code, that can be done simply by catching Natools.Getopt_Long.Option_Error > exception. If one is willing to forgo the nuanced error handling one gets with the exceptional-case handlers in your design and instead have something like this, I'd probably go with a function that returns a list of arguments and raises an exception if that's not possible: Invalid_Argument : exception; type Argument_Info (Has_Option : Boolean := False) is record Number : Positive; -- The argument number for the option, if there is one, or the argument, if -- there is no option. Value : Ada.Strings.Unbounded.Unbounded_String; -- The value of the argument (associated with Option if applicable). case Has_Option is when False => null; when True => Option : Option_ID; -- The option Value is for, if any. end case; end record; type Argument_List is array (Positive range <>) of Argument_Info; function Arguments (Options : in Option_Definition) return Argument_List; -- Processes the arguments on the command line based on Options and returns -- them in Argument_List. -- Raises Invalid_Argument if the arguments cannot be processed according -- to Options (missing the argument to an option that requires one, or an -- unknown option). The exception message can indicate the reason the arguments couldn't be processed ("Missing argument" or "Unknown option") and the offending argument number. Or one could use more specific exceptions, Missing_Argument and Unknown_Option, with the argument number in the exception message. That's pretty much a matter of taste. The ARM seems to prefer blanket exceptions (Argument_Error); I usually like more precision. Including the argument number allows the client to look at the raw arguments if so desired. Yet another design might be to pass unknown options back as non-option arguments and let the client decide what to do with them, in which case a missing argument would be the only exceptional case. Exceptions indicate exceptional situations that the package is not prepared to handle; they are not necessarily errors. That's usually up to the client to decide. So I generally don't like to name exceptions with _Error. A good example is attempting to read past the EOF with Ada.Text_IO. End_Of_File returns True if there's a blank line followed by EOF remaining in the file; the only way to process a final blank line is to read until End_Error is raised. That's not an error; it's a deliberate act by the client in order to properly process the entire file. I'd call it EOF_Encountered. While it seems unlikely, a client might want to allow a client to use one of multiple, mutually exclusive option definitions, in which case the inability to process the arguments is not an error, but an indication that the client should try a different option definition. A couple of other minor comments: The declaration of Option_Error is far from where it is referenced in the spec. I like things to be as close to where they're referenced as possible. The "default" constants are not referenced in the spec. They might be useful as default parameter values, and in the comments that currently refer to their values. HTH. -- Jeff Carter "He didn't get that nose from playing ping-pong." Never Give a Sucker an Even Break 110