While debugging/fixing the logging module's atexit behavior (see
http://www.cherrypy.org/ticket/646 -- it chokes atexit if stdout is
closed), it became difficult to write an automated test that verified
the bug occurred, since it happened at program exit. Returning a nonzero
exit code when atexit errors occur would be preferable to just printing
the error. Of course, if SystemExit is already raised, we should
propagate that out, but other exceptions should print the traceback and
then return some other code IMO.

I am an agreeance with the original report.  I just finished writing an
automated test that did the following to work around this behavior:

 	46	        # Sometimes an exception happens during exit, try to make
sure we get   
 	47	        # a non_zero exit code. 
 	48	        old_exitfunc = sys.exitfunc 
 	49	        def exitfunc(): 
 	50	            try: 
 	51	                old_exitfunc() 
 	52	            except SystemExit: 
 	53	                raise 
 	54	            except: 
 	55	                raise SystemExit(1)

sorry for the noise and duplication.  The full code listing should have
been:

 	46	        # Sometimes an exception happens during exit, try to make
sure we get   
 	47	        # a non_zero exit code. 
 	48	        old_exitfunc = sys.exitfunc 
 	49	        def exitfunc(): 
 	50	            try: 
 	51	                old_exitfunc() 
 	52	            except SystemExit: 
 	53	                raise 
 	54	            except: 
 	55	                raise SystemExit(1) 
 	56	        sys.exitfunc = exitfunc

The issue should be addressed in the C code.

Please see GHOP patches by anders_v...@yahoo.se,

http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=215

I've attached the Python 2.6 patch here.

I'm assigning this to Christian because he was doing the GHOP review.

Can someone please review the attached patch with a view to committing, it contains doc and unit test changes.

exit code = 128 + # of failed atexits

I don't agree with the feature. Do we need something so complex?

I think there is no need to implement this in python2.x since it's a  behavior change which could introduce some compatibility issues to someone's code, besides in 2.x both sys.exitfunc and atexit module should be considered, that makes the code looks complex. The sys.exitfunc is removed in 3.x.

+1 on only implementing it in 3.3.

I would disagree with this report. There are many errors which are effectively silenced by Python, except for being printed on stderr: for example, errors which occur in a __del__ method or a weakref callback (both of which semantically similar to an atexit handler); but also exceptions which terminate a non-main thread.

Python's error code is derived from the return status of the main thread of execution, not counting any kinds of asynchronous exceptions, which are simply displayed and then ignored.

If you want to write a test for errors at program exit, you should check for stderr's contents (by capturing it).

Antoine disagrees with the feature request, so I close it.

You can modify your atexit callbacks to catch exceptions and decide how to handle them: write them into a file, into stderr, etc.

nosy: + vstinner
messages: + msg342549

resolution: rejected
stage: patch review -> resolved

messages: + msg132590
versions: + Python 3.3

messages: + msg116780

stage: patch review