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 r.david.murray
Recipients Chris.Clark, docs@python, r.david.murray
Date 2014-03-12.23:30:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1394667043.95.0.866549696472.issue20903@psf.upfronthosting.co.za>
In-reply-to
Content
In general we don't document what gets raised unless it is unique to a module or has non-obvious implications.  In this case, getting socket exceptions out of a network library should be "obvious" in some sense :).  In particular, both SMTPConnectError and socket.error are subclasses of OSError, so if you want to catch them all, catch OSError.

Now, that said, I have some sympathy to the idea that something triggered by a parameter to the call should perhaps result in an SMTPConnectError.  However, the argument *against* it is that it makes it difficult to differentiate the timeout error from other connection errors, which one might well want to do.  We've moved toward making it easier to tell classes of errors apart (see PEP 3151), so this would be a regression in that approach.

Given that the timeout is part of the signature, I think it does make sense to mention that the timeout will raise a socket.timeout error.
History
Date User Action Args
2014-03-12 23:30:43r.david.murraysetrecipients: + r.david.murray, docs@python, Chris.Clark
2014-03-12 23:30:43r.david.murraysetmessageid: <1394667043.95.0.866549696472.issue20903@psf.upfronthosting.co.za>
2014-03-12 23:30:43r.david.murraylinkissue20903 messages
2014-03-12 23:30:43r.david.murraycreate