Pop return from stack?

[Steven D'Aprano]

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
> found?

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__':
    try:
        main()
    except getopt.GetoptError, e:
        # Unrecoverable error in command line options.
        print e.args[0]
        sys.exit(42)  # or whatever value is appropriate
    except Exception, e:
        log_exception(e)  # whatever...
        raise


SystemExit won't be caught, and will just exit normally. Any other 
exception won't be caught either, but will lead to a traceback.



-- 
Steven