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 lemburg
Recipients Jurko.Gospodnetić, brian.curtin, lemburg, pitrou, tim.golden, tim.peters, vstinner
Date 2013-12-16.09:17:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <52AEC510.1050407@egenix.com>
In-reply-to <1387184549.18.0.248908328227.issue19983@psf.upfronthosting.co.za>
Content
On 16.12.2013 10:02, STINNER Victor wrote:
> 
> Maybe we should modify Py_FatalError() to call exit(1) in release mode, and only call abort() in debug mode? Dumping a core dump, opening a Windows fatal error popup, calling Fedora ABRT handler, etc. is maybe not very useful, especially for the KeyboardInterrupt case.

I don't think changing Py_FatalError() is a good idea. However,
its use in this particular case (streams not initializing) appears
wrong.

Python should simply exit with an error code in such a case; which then
also allows the calling script or application to react to the error.

The fatal error is reserved for cases where you cannot continue
and can't even report back an error, not even as error code.
Those are rare situations. You usually only use abort() if you need
to debug the situation via a core dump, which is not needed in
this case, since we know that the user caused a keyboard
interrupt and in most other cases know that it's a config problem,
not a problem in the C implementation of Python.
History
Date User Action Args
2013-12-16 09:17:07lemburgsetrecipients: + lemburg, tim.peters, pitrou, vstinner, tim.golden, brian.curtin, Jurko.Gospodnetić
2013-12-16 09:17:07lemburglinkissue19983 messages
2013-12-16 09:17:07lemburgcreate