This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rbcollins
Recipients Arfrever, georg.brandl, loewis, martin.panter, mkc, pitrou, python-dev, rbcollins, steve.dower, terry.reedy
Date 2015-08-26.07:40:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1440574851.91.0.663876737311.issue5319@psf.upfronthosting.co.za>
In-reply-to
Content
def main():
   try:
       thing()
   except SomethingChanged:
       exit(1)
   except BinaryDiff:
       exit(2)
   except:
       exit(3)

This is the sort of pattern e.g. 'diff' has. 

Should exit(3) there become exit(1) ? exit(1) means 'succeeded and there were changes'. So no, 3,for this app, means 'broke entirely'.

Exiting with '1' is also poor/confusing for this app. So perhaps we should pick something rarely used - like 255. But anyhow the same logic applies: if an app signals 'error' with a different code, we shouldn't change the apps 'error' signal to be something else when we detect an error.

But OTOH preserving a non-zero not-error code when an error occurs is also wrong.

So I think, on reflection:
 1) pick an unusual code. Not 1. Not 77 (automake test skip code). Maybe 255? https://www.freebsd.org/cgi/man.cgi?query=sysexits&sektion=3&apropos=0&manpath=FreeBSD+10.2-RELEASE defines some codes we should avoid as well.
 2) We document that python itself may cause this exit code to be used and that apps written in python should never use that code
 3) we use your patch as it is - on shutdown error force it to this chosen value.

What do you think?
History
Date User Action Args
2015-08-26 07:40:51rbcollinssetrecipients: + rbcollins, loewis, georg.brandl, terry.reedy, mkc, pitrou, Arfrever, python-dev, martin.panter, steve.dower
2015-08-26 07:40:51rbcollinssetmessageid: <1440574851.91.0.663876737311.issue5319@psf.upfronthosting.co.za>
2015-08-26 07:40:51rbcollinslinkissue5319 messages
2015-08-26 07:40:50rbcollinscreate