classification
Title: sys.exit() called from optparse - bad, bad, bad
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.0, Python 2.6, Python 2.5
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: Phillip.M.Feldman@gmail.com, georg.brandl, ggenellina, pitrou, r.david.murray, skip.montanaro
Priority: normal Keywords: easy

Created on 2008-06-11 17:23 by skip.montanaro, last changed 2009-10-16 03:33 by Phillip.M.Feldman@gmail.com. This issue is now closed.

Messages (7)
msg67999 - (view) Author: Skip Montanaro (skip.montanaro) * Date: 2008-06-11 17:23
This seems like a bug in optparse.OptionParser:

    def exit(self, status=0, msg=None):
        if msg:
            sys.stderr.write(msg)
        sys.exit(status)

    def error(self, msg):
        """error(msg : string)

        Print a usage message incorporating 'msg' to stderr and exit.
        If you override this in a subclass, it should not return -- it
        should either exit or raise an exception.
        """
        self.print_usage(sys.stderr)
        self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))

By default I think it should raise an exception when it encounters an
error, not exit.  Programmers shouldn't be forced to subclass code in
the standard library to get recommended practice.

If you feel this behavior can't be changed in 2.6 it should at least
be corrected in 3.0.

The cruel irony is that inside OptionParser.parse_args it actually
catches both BadOptionError and OptionValueError but suppresses them
by calling self.error() within the except block...  *arrgggghhh*...
The correct behavior there is (in my opinion) to get rid of the
try/except statement altogether and just let the exceptions propagate.
Other calls to self.error() should be replaced with suitable raise
statements.

Skip
msg68149 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-06-13 12:34
The current behaviour is useful in that most of time, it is convenient
to let OptionParser display a standard error message and bail out.
However, having an attribute on the OptionParser object (e.g.
exit_on_errors) to be able to change this behaviour is a reasonable
proposition.
msg68156 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-06-13 13:27
I agree with Antoine that the standard behavior is what you want in most
simple command-line scripts.

It's easy enough to replace the parser's exit function to just print the
message, or raise an exception.
msg68171 - (view) Author: Skip Montanaro (skip.montanaro) * Date: 2008-06-13 16:46
Georg> I agree with Antoine that the standard behavior is what you want in most
    Georg> simple command-line scripts.

    Georg> It's easy enough to replace the parser's exit function to just print the
    Georg> message, or raise an exception.

Check the code.  Most of the time error is called without an exception
having been raised.  In one case it actually is called and swallows an
exception that the code did raise.  It would be preferable in my mind to
always raise an exception.  If you want, the default can be to catch them
and ignore them as error() does now, but as it stands you can't raise
anything more specific than OptParseError, and that's just a punt even
though specific problems were detected by the code.

Skip
msg94114 - (view) Author: Phillip M. Feldman (Phillip.M.Feldman@gmail.com) Date: 2009-10-16 00:03
The current behavior of optparse is contrary to how most of Python
works. optparse should throw a named exception that can be trapped and
identified by the calling program.  Doing a SystemExit is unacceptable.
 I can't believe that this is such a hard thing to fix.
msg94116 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2009-10-16 00:36
There was recently a long discussion of this on python-dev (in the
context of a proposal to add argparse to the stdlib; argparse does the
same thing).  The conclusion was that the current behavior is the most
useful behavior, and that if you don't want to exit you can either
subclass or catch SystemExit.
msg94122 - (view) Author: Phillip M. Feldman (Phillip.M.Feldman@gmail.com) Date: 2009-10-16 03:33
Thanks for the response!

I can indeed catch SystemExit, but I would like to be able to take one 
action (terminate the program) if the user supplied an unknown option, 
and another action (prompt for a new value) if the user supplied a bad 
value for an option.  I suspect that I can achieve this by subclassing, 
but I'm not yet at that level of Python sophistication.

Yours,

Phillip

R. David Murray wrote:
> R. David Murray <rdmurray@bitdance.com> added the comment:
>
> There was recently a long discussion of this on python-dev (in the
> context of a proposal to add argparse to the stdlib; argparse does the
> same thing).  The conclusion was that the current behavior is the most
> useful behavior, and that if you don't want to exit you can either
> subclass or catch SystemExit.
>
> ----------
> nosy: +r.david.murray
> resolution:  -> wont fix
> stage:  -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3079>
> _______________________________________
>
>
History
Date User Action Args
2009-10-16 03:33:12Phillip.M.Feldman@gmail.comsetmessages: + msg94122
2009-10-16 00:36:50r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg94116

resolution: wont fix
stage: resolved
2009-10-16 00:03:46Phillip.M.Feldman@gmail.comsetnosy: + Phillip.M.Feldman@gmail.com
messages: + msg94114
2008-06-13 16:46:57skip.montanarosetmessages: + msg68171
2008-06-13 13:27:01georg.brandlsetnosy: + georg.brandl
messages: + msg68156
2008-06-13 12:34:12pitrousetnosy: + pitrou
messages: + msg68149
2008-06-13 02:12:37ggenellinasetnosy: + ggenellina
2008-06-11 23:46:47skip.montanarolinkissue3084 superseder
2008-06-11 17:30:55skip.montanarosetversions: + Python 2.6, Python 3.0
2008-06-11 17:23:27skip.montanarocreate