Re: Starter project: getopt_long in Ada

[Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>]

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