Pop return from stack?
steve at REMOVE-THIS-cybersource.com.au
Mon Aug 16 13:44:06 CEST 2010
On Sun, 15 Aug 2010 18:43:49 -0700, bvdp wrote:
> However, I have gotten hit with more than one comment like yours. So,
> could you please clarify? Is it bad form to exit an application with
> sys.exit(1) when an error in a file the application is processing is
My two cents worth...
The distinction I like to make is between *planned* and *unplanned*
exits. Planned exits are things like the user choosing Quit from the
menu, or a command line tool exiting after printing a usage message.
"Exit the application" is part of the application's user interface, and
therefore it is appropriate to exit the application. These aren't errors,
the exception isn't called "SystemError" but SystemExit, and it's not
necessary to print a traceback.
Such exits should usually only exist in the front-end (user-interface)
code, rarely or never in the back-end.
But *unplanned* exits are errors, and so you should not disguise them as
planned exits by raising SystemExit, any more than you would disguise
them as a keyboard interruption by raising KeyboardInterrupt. Raise an
appropriate exception, and let Python's normal exception-handling code
clean up and exit for you.
I make one more design choice: if there's an unrecoverable error in user
input (as opposed unexpectedly bad data or a program bug), I suppress the
traceback, but any other unrecoverable error, I allow it to print.
Something vaguely like this:
if __name__ == '__main__':
except getopt.GetoptError, e:
# Unrecoverable error in command line options.
sys.exit(42) # or whatever value is appropriate
except Exception, e:
log_exception(e) # whatever...
SystemExit won't be caught, and will just exit normally. Any other
exception won't be caught either, but will lead to a traceback.
More information about the Python-list