Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Public subclasses of OptionException #58
Hi @andrewbts, thanks for your interest!
My thinking in keeping the subclasses of OptionException package-private was that an OptionException, no matter its leaf type, would pretty much be handled in the same way: show the exception's message on the console, maybe its stack trace, and exit. Because of this, the specific type wouldn't be important. So I decided to keep them package-private, thereby reducing the surface of the public (and published) API.
Also, keeping the specific types hidden (an implementation detail, if you will) affords us the freedom to rename/remove/refactor them without worrying about breaking callers.
I'm willing to reconsider this decision. I'm interested to hear what different strategies you'd use to handle different subclasses of OptionException. Do the messages in the exceptions not contain enough info? need internationalized?
Hi, thanks for you reply. I did proceed as you had anticipated: Printing the message in the OptionException, print the help, and exit.
What I was planning on doing, motivating me to create this Issue, was:
But I think considering the goals of the library the current behavior is fine.
One thing that troubled me (not enough to change it :) ) is that the message for missing required options includes all synonyms of the missing required options:
Here I have two options
Not easy to see how to get around it through, without introducing some notion of the "preferred" form/name for an option.
@andrewbts I see what you're getting at. I wonder if changing the message of exception MissingRequiredOptionException (and other exceptions that have the context of all synonyms of an option) to indicate that these are synonyms would help? Maybe something like:
This doesn't introduce any notion of a preferred synonym, but perhaps wouldn't give the impression that four required options are missing?
Interesting idea. I think I prefer the old message to this though, since the new one could be confusing to end-users of command line tools. If they are not familiar with jopt-simple, they may think the message implies something about a "synonym" option.
Any prospect for grouping the listed option names by synonymity?
added a commit
Apr 6, 2014
Hi @andrewbts, I have a branch called 'exception-message-experiment' containing some changes to the exception messaging. Have a look, if you please, and see whether these changes suit you.
There are some API changes to support this -- mostly accepting lists of option specs rather than collections, renaming some exceptions (thank goodness they aren't part of the public API!), etc.
Bringing @binkley in on this also so he can weigh with his opinions.