clarify how to return runtime errors about cli11 HOT 5 CLOSED

It's smarter to keep RuntimeError and ParseError siblings, so that's what I did in #45.

from cli11.

Two initial thoughts:

• This really makes CLI11_PARSE the recommended/required way to exit. For someone not using CLI11_PARSE, you should be able to do:

try {
    app.parse(argc, argv);
} catch (const CLI::Error &e) {
    return app.exit(e);
}

(I'm okay if CLI::ParseError isn't enough)

• It might make sense to move CLI::Success to a CLI::RuntimeError too. No, I think it works fine as is.

I'll probably push to the PR in a minute.

from cli11.

That's ok. I was worried that catching CLI::Error is too grabby, because the other errors are more like programming errors (such as adding options twice), which I thought CLI11_PARSE doesn't catch purposefully. Thanks!

from cli11.

The other errors cannot be thrown from .parse, though sometimes users wrap too much in the try block. I think leaving CLI11_PARSE as less grabby is a good idea, but direct usage should be at least possible catching CLI::Error.

from cli11.

I've made RuntimeError a ParseError, since it can only happen at parse time, and will leave the Error catching as ParseError catching. This has the smallest API change.

from cli11.