Exception Handling and Exit Codes — Click Documentation (8.3.x)
Click internally uses exceptions to signal various error conditions that the user of the application might have caused. Primarily this is things like incorrect usage.
Where are Errors Handled?¶
Click’s main error handling is happening in Command.main(). In
there it handles all subclasses of ClickException as well as the
standard EOFError and KeyboardInterrupt exceptions. The
latter are internally translated into an Abort.
The logic applied is the following:
If an
EOFErrororKeyboardInterrupthappens, reraise it asAbort.If a
ClickExceptionis raised, invoke theClickException.show()method on it to display it and then exit the program withClickException.exit_code.If an
Abortexception is raised print the stringAborted!to standard error and exit the program with exit code1.If it goes through well, exit the program with exit code
0.
What if I Don’t Want That?¶
Generally you always have the option to invoke the Command.invoke()
method yourself. For instance if you have a Command you can
invoke it manually like this:
ctx = command.make_context("command-name", ["args", "go", "here"]) with ctx: result = command.invoke(ctx)
In this case exceptions will not be handled at all and bubbled up as you would expect.
Starting with Click 3.0 you can also use the Command.main() method
but disable the standalone mode which will do two things: disable
exception handling and disable the implicit sys.exit() at the end.
So you can do something like this:
command.main( ["command-name", "args", "go", "here"], standalone_mode=False, )
Which Exceptions Exist?¶
Click has two exception bases: ClickException which is raised for
all exceptions that Click wants to signal to the user and Abort
which is used to instruct Click to abort the execution.
A ClickException has a ClickException.show() method which
can render an error message to stderr or the given file object. If you
want to use the exception yourself for doing something check the API docs
about what else they provide.
The following common subclasses exist:
UsageErrorto inform the user that something went wrong.BadParameterto inform the user that something went wrong with a specific parameter. These are often handled internally in Click and augmented with extra information if possible. For instance if those are raised from a callback Click will automatically augment it with the parameter name if possible.FileErrorthis is an error that is raised by theFileTypeif Click encounters issues opening the file.
Help Pages and Exit Codes¶
Triggering the a help page intentionally (by passing in --help)
returns exit code 0. If a help page is displayed due to incorrect user
input, the program returns exit code 2. See Exit Codes for more
general information.
For clarity, here is an example.
@click.group('printer_group') def printer_group(): pass @printer_group.command('printer') @click.option('--this') def printer(this): if this: click.echo(this)
$ printer-group --help Usage: printer-group [OPTIONS] COMMAND [ARGS]... Options: --help Show this message and exit. Commands: printer
The above invocation returns exit code 0.
$ printer-group Usage: printer-group [OPTIONS] COMMAND [ARGS]... Options: --help Show this message and exit. Commands: printer
The above invocation returns exit code 2 since the user invoked the command incorrectly. However, since this is such a common error when first using a command, Click invokes the help page for the user. To see that printer-group is an invalid invocation, turn no_args_is_help off.
@click.group('printer_group', no_args_is_help=False) def printer_group(): pass @printer_group.command('printer') @click.option('--this') def printer(this): if this: click.echo(this)
$ printer-group Usage: printer-group [OPTIONS] COMMAND [ARGS]... Try 'printer-group --help' for help. Error: Missing command.