Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide ability to find which subcommand threw a ParameterException #207

Closed
remkop opened this issue Oct 16, 2017 · 1 comment
Closed

Provide ability to find which subcommand threw a ParameterException #207

remkop opened this issue Oct 16, 2017 · 1 comment

Comments

@remkop
Copy link
Owner

remkop commented Oct 16, 2017

If a command has multiple subcommands, and if the parse method threw a ParameterException, it is not possible to find out which subcommand threw the exception. This means it is not possible to give specific usage help feedback to the user on how the subcommand should be used correctly.

Solution: add method ParameterException::getCommandLine that returns the (sub)command that threw the exception. Client code could look like this:

CommandLine top = new CommandLine(new MyApp());
try {
    List<CommandLine> parsedCommands = top.parse(args);
    // ... do something with the parsed commands
} catch (ParameterException ex) { // incorrect user input for one of the subcommands
    out.println(ex.getMessage());
    ex.getCommandLine().usage(out); // get the offended subcommand from the exception
}

To implement this, change the ParameterException constructor (and similar for all subclasses) to add a required CommandLine parameter.

Note to self: the ParameterException hierarchy needs to be refactored. Exceptions thrown from the CommandLine constructor should not extend from ParameterException. Let's introduce a new ConfigurationException (extends RuntimeException) to indicate a CommandLine could not be constructed. DuplicateOptionAnnotationException and ParameterIndexGapException should extend this new exception. CommandLine constructor code throwing IllegalArgumentException and IllegalStateException should throw a ConfigurationException instead.

The remaining exceptions can extend ParameterException, and CommandLine can be a mandatory ParameterException constructor parameter.

These are breaking API changes, so require a major version increment.

@remkop
Copy link
Owner Author

remkop commented Oct 16, 2017

This has been implemented and pushed to master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant