Skip to content
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

Improved error messages and DocoptExit #63

wants to merge 1 commit into
base: master
Choose a base branch


Copy link

@ghost ghost commented Oct 17, 2012

Error messages fixed pursuant of #43. There's also a new method, docopt.exit(), that behaves exactly like sys.exit() when called with None or an integer argument, but prepends the argument with the program name and appends it with an usage message when called with anything else. DocoptExit was changed to reflect this. (The program name is read from the docstring, not sys.argv[0].)

I also changed the error message given on a failed usage pattern match to missing operand(s), as missing operand is what GNU programs say when you give them too few arguments. This probably still needs improvement, because a pattern mismatch can also happen in a few corner cases where there is technically no "missing operand", I think.

@ghost ghost mentioned this pull request Oct 17, 2012
Copy link

Do you think that docopt.exit is useful? Not sure about "missing operand(s)" either.

Copy link

ghost commented Oct 17, 2012

It's kind of tangential to docopt's purpose, but docopt.exit is useful if one wishes to maintain a consistent look in the error messages a program gives -- less boilerplate and nicer than raise DocoptExit(arg). Regarding "missing operand(s)", I mostly put it in there because DocoptExit now prepends the program name to the error message, so calling something with an invalid usage pattern would show something like

Usage: prog [options] <argument>

which just looks silly, and coming up with an error message for that case seemed saner than coding an exception. However, I'm not sure myself what the error message should say. Precise diagnostics on exactly where the invocation failed would be nice, but I haven't familiarized myself with pattern.fix().match(argv) enough to know how to implement that, or if it's even possible.

Copy link

Zearin commented Apr 28, 2015

@ghost : I’m not clear on your second explanation. I think what you’re saying is this:

“When the user invokes the program with an invalid usage pattern, it’s more helpful to get an error that points to the invalid part(s), instead of just printing the entire Usage pattern.”

Is that right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants