-
Notifications
You must be signed in to change notification settings - Fork 418
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
@Parameters validation and error messages if arity > 0 is buggy #203
Comments
I'm testing this with current master (2.0.0-SNAPSHOT) and I can reproduce what you are seeing. However, I see a problem in the test. The |
After removing the Mostly, but not completely. I agree that the difference between the Type1 and the Type2 exceptions is strange. The second case seems okay: both the required In the first case, an empty string parameter is passed. I would expect this to be parsed as a positional parameter (an The fix has been pushed to master and I added your example as a new set of test cases ( Thanks for raising this! Please verify that master behaves as expected now. |
@remkop I think the decision to stop parsing and validating if the (edited) Regards. |
You raise some good points. Would you mind creating a new ticket? |
FYI, I just started to work on #115 which aims to provide convenience methods for printing help and executing Runnable commands, even in applications with nested subcommands. Some work in progress is now in master. See the CommandLine::parseWithHandler(s) methods. |
I created #207 to Provide ability to find which subcommand threw a ParameterException. |
See also my comment here showing some idiomatic code for |
Thanks @remkop ! |
PicoCLI version:
1.0.1
I have a class annotated with
@Parameters(arity = "1..*", description = "The input files")
and discovered somethings about the validation ofarity >= 1
:""
) or zero-length String[] (new String[0]
) is supplied to theparse(xx)
methodType 1 exception:
Type 2 exception:
The text was updated successfully, but these errors were encountered: