Specific error message about optparse-applicative HOT 8 CLOSED

"Unknown option" errors should work already. If you have an example where they don't, please open a separate ticket.

Some of the other errors can be manually specified by using a custom reader and the noArgError modifier, e.g.:

nullOption (  long "hello"
           <> metavar "TARGET"
           <> reader (\s -> msum
                [ auto s
                , readerError "expected int" ])
           <> noArgError (ErrorMsg "missing int parameter") )

but I do agree that the defaults should be more informative.

from optparse-applicative.

On Sat, 26 Oct 2013, Paolo Capriotti wrote:

"Unknown option" errors should work already. If you have an example
where they don't, please open a separate ticket.

I am refering to the example given in the docs:
http://hackage.haskell.org/package/optparse-applicative-0.7.0.2

from optparse-applicative.

When running the example, I get:

$ ./sample --foo
Invalid option `--foo'

Usage: sample --hello TARGET [--quiet]

Am I missing something?

from optparse-applicative.

On Sat, 26 Oct 2013, Paolo Capriotti wrote:

When running the example, I get:

$ ./sample --foo
Invalid option `--foo'

Usage: sample --hello TARGET [--quiet]

Am I missing something?

I get the same result for this example. However, I don't want the general
"Usage" message, if there is a specific error.

Also I tried "--hello" without an argument and I tried "--quiet" without
"--hello" and got no specific error message in both cases.

from optparse-applicative.

Why not? If the user specified an invalid option, it is likely that they are confused about the available options, and the "usage" message can be helpful. I don't think it hurts either way.

I guess I could add a preference to never display the usage message when a more specific error can be displayed, but I'd rather limit the number of such preferences.

With the changes in the formatting branch, it should be relatively easy to use execPureParser and then do the error reporting yourself, if you're not happy with how execParser does it.

from optparse-applicative.

On Sat, 26 Oct 2013, Paolo Capriotti wrote:

Why not? If the user specified an invalid option, it is likely that they
are confused about the available options, and the "usage" message can be
helpful. I don't think it hurts either way.

In my experience it means that I have just mistyped an option or forgot
something. The Usage message can become rather long and would distract me
from the real error message. If it is a more complex problem I may have to
make more attempts. In this case the terminal is quickly filled with the
repeating "Usage" message that has no value anymore after the first time.
Last but not least, most shell commands only report the general usage
message if asked to do so.

With the changes in the formatting branch, it should be relatively easy
to use execPureParser and then do the error reporting yourself, if
you're not happy with how execParser does it.

ok

from optparse-applicative.

github has hidden my additional comment:

On Sat, 26 Oct 2013, amigalemming wrote:

Also I tried "--hello" without an argument and I tried "--quiet" without
"--hello" and got no specific error message in both cases.

from optparse-applicative.

next attempt:

Also I tried "--hello" without an argument and I tried "--quiet" without
"--hello" and got no specific error message in both cases.

from optparse-applicative.