Argparse.parse_args exits on unrecognized option with exit_on_error=False

[matthewhughes934]

BPO	41255
Nosy	@rhettinger, @tirkarthi, @matthewhughes934, @jacobtylerwalls, @bigbirdcode, @joshmeranda
PRs	bpo-41255: handle argparse errors with exit_on_error=False consistently #27295 gh-85427: Prevent exits if ArgumentParser.exit_on_error is False #30832
Files	exit_on_error_tests.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-07-09.08:40:33.198>
labels = ['type-bug', 'library', '3.9']
title = 'Argparse.parse_args exits on unrecognized option with exit_on_error=False'
updated_at = <Date 2022-01-29.03:10:17.942>
user = 'https://github.com/matthewhughes934'

bugs.python.org fields:

activity = <Date 2022-01-29.03:10:17.942>
actor = 'jacobtylerwalls'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-07-09.08:40:33.198>
creator = 'mhughes'
dependencies = []
files = ['49310']
hgrepos = []
issue_num = 41255
keywords = ['patch']
message_count = 10.0
messages = ['373382', '373383', '373385', '373405', '373437', '373440', '373470', '396345', '397975', '401629']
nosy_count = 7.0
nosy_names = ['rhettinger', 'paul.j3', 'xtreak', 'mhughes', 'jacobtylerwalls', 'bigbird', 'joshmeranda']
pr_nums = ['27295', '30832']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue41255'
versions = ['Python 3.9']

[matthewhughes934]

>>> import argparse
    >>> parser = argparse.ArgumentParser(exit_on_error=False)
    >>> parser.parse_args(["--unknown"])
    usage: [-h]
    : error: unrecognized arguments: --unknown

The docs https://docs.python.org/3.10/library/argparse.html#exit-on-error say:

Normally, when you pass an invalid argument list to the parse_args() method of an ArgumentParser, it will exit with error info.
If the user would like catch errors manually, the feature can be enable by setting exit_on_error to False:

This description _appears_ to be at odds with the observed behavior.

[tirkarthi]

I guess the docs by manually mean that ArgumentError will be raised when exit_on_error is False that can be handled. By default with exit_on_error being True self.error() which raises SystemExit and catching SystemExit can mask other errors. This was added in bpo-9938 with #59567. There is also a typo in the docs that it should have used enabled instead of enable in "the feature can be enable by setting exit_on_error to False"

[matthewhughes934]

typo in the docs that it should have used enabled instead of enable

Well spotted, I'll happily fix this up.

I guess the docs by manually mean that ArgumentError will be raised when exit_on_error is False that can be handled.

To be clear, in this case, even with exit_on_error=False, ArgumentError is _not_ being raised, but SystemExit is.

[matthewhughes934]

I've attached a patch containing tests showing the current behavior, namely that exit_on_error does not change the behavior of argparse.ArgumentParser.parse_args in either case:

• An unrecognized option is given
• A required option is not given

Should the docs be updated to note this?

[paulj3]

I didn't pay attention to the patch that added this "exit_on_error" parameter. So I don't know exactly what error handling it was supposed to handle or why. But given the location of the code change, it does not handle every possible error.

Specifically it's in parser.parse_known_args() where it calls _parse_known_args(). With this parameter True, a argparse.ArgumentError is caught and converted to parse.error() call. That's the original behavior.

With False, there's no special handling for ArgumentError. Catching that is left to the developer, as illustrated in the docs.

In the documented example, it's a 'type' error. 'choices' would also behave this way. 'nargs' errors also. But not all errors are handled like this.

Inside _parse_known_args(), self.error() is called several times, once for 'required' arguments failure, and for a required mutually_exclusive_group error. I count 9 self.error() calls; exit_on_error only changes one of those.

The error highlighted in this issue is called in parser.parse_args(). This calls parse_known_args(), and raises an error if there are 'extras', unrecognized strings.

So clearly the new docs is is describing this new parameter in overly broad terms. It only changes the handling of a subset of parser.error() calls. Off hand I can't think of clean way of refining the description without getting overly technical about the error handling.

Developers already had the documented option of changing the parse.error() and parse.exit() methods.