argparse.ArgumentParser.parses_args does not honor exit_on_error=False when given unrecognized arguments

[blhsing]

Bug report

Bug description:

As reported in Discourse, even though the documentation on the exit_on_error argument for argparse.ArgumentParser says:

exit_on_error - Determines whether or not ArgumentParser exits with error info when an error occurs. (default: True)

The parse_args method would still exit with error info when there are unrecognized arguments:

import argparse
parser = argparse.ArgumentParser(exit_on_error=False)
try:
    parser.parse_args('invalid arguments'.split())
except argparse.ArgumentError:
    print('ArgumentError caught.')

which outputs:

usage: test.py [-h]
test.py: error: unrecognized arguments: invalid arguments

CPython versions tested on:

3.12, CPython main branch

Operating systems tested on:

Linux, Windows

Linked PRs

• gh-121018: ensure ArgumentParser.parse_args with exit_on_error=False raises instead of exiting when given unrecognized arguments #121019
• [3.12] gh-121018: Ensure ArgumentParser.parse_args with exit_on_error=False raises instead of exiting when given unrecognized arguments (GH-121019) #121031
• [3.13] gh-121018: Ensure ArgumentParser.parse_args with exit_on_error=False raises instead of exiting when given unrecognized arguments (GH-121019) #121032
• gh-121018: Fix more cases of exiting in argparse when exit_on_error=False #121056
• [3.13] gh-121018: Fix more cases of exiting in argparse when exit_on_error=False (GH-121056) #121128
• [3.12] gh-121018: Fix more cases of exiting in argparse when exit_on_error=False (GH-121056) #121129
• gh-121018: Fix typo in NEWS entry #121510
• [3.12] gh-121018: Fix typo in NEWS entry (GH-121510) #121516

[serhiy-storchaka]

Actually, this is more complex issue. error() is called in many other places, and it does not honor exit_on_error=False.

In most cases it can be replaced with raise ArgumentError. It is caught at higher level and error() is called if exit_on_error is true.

In some cases ValueError may be more appropriate exception than ArgumentError, but this is another issue.

[blhsing]

Actually, this is more complex issue. error() is called in many other places, and it does not honor exit_on_error=False.

In most cases it can be replaced with raise ArgumentError. It is caught at higher level and error() is called if exit_on_error is true.

In some cases ValueError may be more appropriate exception than ArgumentError, but this is another issue.

Ah yes good catch. I think ArgumentError is meant to be raised by invalid arguments given by the end user. In cases where the error is caused by an improper setup of a parser or an option from the developer, a ValueError would indeed be more appropriate.

[blhsing]

On second thought, I think it may be cleaner to simply put the if self.exit_on_error: ... else: raise ArgumentError logics directly in the error method, and call self.error only when it is caused by the end user.

[serhiy-storchaka]

There are already open issues for this bug: #85427 and #103498. It is my fault that I did not recognize duplicates.

Yes, putting the logic directly in the error method could simplify some cases, but we want exit_on_error=False to work even with user-overridden error method.

[blhsing]

There are already open issues for this bug: #85427 and #103498. It is my fault that I did not recognize duplicates.

Ah you're right. I forgot to search for prior bug reports before filing mine. Sorry.

Yes, putting the logic directly in the error method could simplify some cases, but we want exit_on_error=False to work even with user-overridden error method.

Good point. Will keep the current approach then. Thanks!