-
Notifications
You must be signed in to change notification settings - Fork 191
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
Fix for CLI-340 #334
base: master
Are you sure you want to change the base?
Fix for CLI-340 #334
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @Claudenw
- See exception management comment (rebase on git master svp)
- For all Javadoc of new methods: Can the method return null? If so, when? What happens if the option does not exist?
- Are all these APIs really needed? Couldn't we just add a minimal set following the YAGNI principle. Not my use case, so you tell me ;-)
result[i] = clazz.cast(option.getConverter().apply(values[i])); | ||
} | ||
return result; | ||
} catch (Throwable t) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Catching Throwable
is a bit of an anti-pattern here IMO because you certainly don't want to demote Error
s as ParseException
s
You should catch more specific exceptions, even if means catching all of Exception
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I was following the pattern from getParsedValue()
. I will fix it there as well, but since the Converter throws Throwable we have to deal with it as a Throwable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not anymore ;-) Please rebase git on master (my comment from the preview review).
@@ -691,6 +692,203 @@ public <T> T getParsedOptionValue(final String opt, final T defaultValue) throws | |||
return getParsedOptionValue(resolveOption(opt), defaultValue); | |||
} | |||
|
|||
/** | |||
* Gets a version of this {@code Option} converted to an array of a particular type. | |||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can the method return null? If so, when? What happens if the option does not exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As with all the value getter methods if the option is not in the command line null
is returned unless the default value is defined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, then please update the Javadoc instead of writing it up here ;-)
* @see PatternOptionBuilder | ||
* @since 1.10.0 | ||
*/ | ||
public <T> T[] getParsedOptionValues(final char opt) throws ParseException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to abbreviate IMO: opt
-> option
. Also, using opt
in Javadoc makes for awkward reading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am following the pattern used in the class. Methods from earlier versions used opt
, I elected to do the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it's slightly awkward (to me) to read "@param opt the name of the option." If 'opt' is the name, then why not call it 'name' or 'optionName'? Might as well do the best we can for new code. We can fix the rest separately if you want or do it all in this PR since.
I updated the javadoc to reflect the null or default value return as appropriate. I also updated the javadoc for the
There are all here because they follow the same pattern as getParsedOptionValue() methods. I think they need to be here because V1 supports all those access methods for getOptionValue, getParsedOptionValue, and getOptionValues. I think that in V2 I would limit each set to 4 implementations getOptionValue(Option), getOptionValue(OptionGroup), getOptionValue(Option, default), and getOptionValue(OptionGroup, default). The char and String versions are just fluff. I think that since the application has to create the Options it can keep them around and use them directly without referring to the char or String versions keys. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @Claudenw
I've added 3 comments.
result[i] = clazz.cast(option.getConverter().apply(values[i])); | ||
} | ||
return result; | ||
} catch (Throwable t) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not anymore ;-) Please rebase git on master (my comment from the preview review).
@@ -691,6 +692,203 @@ public <T> T getParsedOptionValue(final String opt, final T defaultValue) throws | |||
return getParsedOptionValue(resolveOption(opt), defaultValue); | |||
} | |||
|
|||
/** | |||
* Gets a version of this {@code Option} converted to an array of a particular type. | |||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, then please update the Javadoc instead of writing it up here ;-)
* @see PatternOptionBuilder | ||
* @since 1.10.0 | ||
*/ | ||
public <T> T[] getParsedOptionValues(final char opt) throws ParseException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it's slightly awkward (to me) to read "@param opt the name of the option." If 'opt' is the name, then why not call it 'name' or 'optionName'? Might as well do the best we can for new code. We can fix the rest separately if you want or do it all in this PR since.
d1df605
to
a55b1ff
Compare
If you want me to change "opt" to "option" throughout the CommandLine class I'll do it. But having some method params be "opt" and others be "option" seems sloppy. |
Hi @Claudenw |
Fix for CLI-340 (add
getParsedOptionValues()
)fix a minor formatting issue in Help javadoc.