Processing of empty args with required parameters AND help=true for one of the declared parameters

[uded]

trafficstars

I am not 100% sure if it is a desired scenario or not, but it is hard for me to agree with the way the empty list of parameters is handled.

Let say I have a class of parameters like this:

@Parameters(resourceBundle = "CLIParameters")
public class CLIParameters {
    @Parameter(names = { "-h", "-?", "--help" }, descriptionKey = "help", help = true)
    private boolean help;

    @Parameter(names = { "-class", "--className" }, descriptionKey = "class", required = true)
    private String className;

When I am going to call this parameters via regular:

CLIParameters params = new CLIParameters();
new JCommander(params).parse("");

An runtime exception of type ParameterException will be raised with a message like this:

com.beust.jcommander.ParameterException: The following options are required: -class, --className

Overall the behaviour is OK, but on the other hand I would expect - in case when none of the required parameters are given - either a regular exception being thrown so I would be able to handle the situation on my or a more meaningful message with usage being shown to the user. The later scenario, in my opinion, is worse as it would still give me no control at all.

Personally I would like JCommander to throw a more complex Exception that would enable the developer to either handle the issue and compose his/her own message to the user or to use the one composed within JCommander. But overall I would accept the scenario in which, if the help=true was declared within the list of parameters, JCommander can automatically provide a default way to handle the situation by printing a meaningful message followed by usage().

Right now the only option for this scenario is to:

CLIParameters params = new CLIParameters();
JCommander jCommander = new JCommander(params);
try {
    jCommander.parse(args);
} catch (ParameterException e) {
    // Handle everything on your own, i.e.
    System.out.println("Error: " + e.getLocalizedMessage());
    System.out.println();
    jCommander.usage();
}

[cbeust]

Sounds reasonable, throwing any subclass of ParameterException would be backward compatible, so fine by me. Would you be willing to send me a pull request?

Cédric

On Sun, Jan 20, 2013 at 9:38 AM, Łukasz Rżanek [email protected]:

I am not 100% sure if it is a desired scenario or not, but it is hard for me to agree with the way the empty list of parameters is handled.

Let say I have a class of parameters like this:

@Parameters(resourceBundle = "CLIParameters")public class CLIParameters { @Parameter(names = { "-h", "-?", "--help" }, descriptionKey = "help", help = true) private boolean help;

@Parameter(names = { "-class", "--className" }, descriptionKey = "class", required = true)
private String className;

When I am going to call this parameters via regular:

CLIParameters params = new CLIParameters();new JCommander(params).parse("");

An runtime exception of type ParameterException will be raised with a message like this:

com.beust.jcommander.ParameterException: The following options are required: -class, --className

Overall the behaviour is OK, but on the other hand I would expect - in case when none of the required parameters are given - either a regular exception being thrown so I would be able to handle the situation on my or a more meaningful message with usage being shown to the user. The later scenario, in my opinion, is worse as it would still give me no control at all.

Personally I would like JCommander to throw a more complex Exception that would enable the developer to either handle the issue and compose he/her own message to the user (that may or may not be followed by usage() - it is not me to make a call here) or to use the one composed within JCommander. Additionally, maybe if the help=true is declared within the list of parameters usage() may be shown to the user as default scenario.

— Reply to this email directly or view it on GitHubhttps://github.com/cbeust/jcommander/issues/149.

[opticyclic]

Are we just throwing subclass of ParameterException? Or print usage() and throw a subclass of ParameterException? Or print usage() and throw ParameterException? Or print usage() and do not throw an exception?

There are 2 scenarios here:

• help=true is defined
• help=true is not defined

Which of the options should be used for each or is the expected behaviour the same for both?