socket.error exceptions not subclass of StandardError #44892
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = 'https://github.com/gpshead' closed_at = <Date 2007-09-09.23:38:26.046> created_at = <Date 2007-04-24.18:09:54.000> labels = ['library'] title = 'socket.error exceptions not subclass of StandardError' updated_at = <Date 2007-09-09.23:38:26.044> user = 'https://bugs.python.org/nagle'
activity = <Date 2007-09-09.23:38:26.044> actor = 'gregory.p.smith' assignee = 'gregory.p.smith' closed = True closed_date = <Date 2007-09-09.23:38:26.046> closer = 'gregory.p.smith' components = ['Library (Lib)'] creation = <Date 2007-04-24.18:09:54.000> creator = 'nagle' dependencies =  files = ['2359'] hgrepos =  issue_num = 1706815 keywords =  message_count = 7.0 messages = ['31874', '31875', '31876', '31877', '55301', '55302', '55770'] nosy_count = 3.0 nosy_names = ['gregory.p.smith', 'janssen', 'nagle'] pr_nums =  priority = 'normal' resolution = 'fixed' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue1706815' versions = 
The text was updated successfully, but these errors were encountered:
The "socket.error" exception is a subclass of Exception, but not of StandardError. It needs to be placed properly in the exception hierarchy, presumably somewhere under IOError.
Socket errors have some known problems. See also:
[ 805194 ] Inappropriate error received using socket timeout
Just figuring out what exceptions can be raised from the socket module is tough. I've seen exceptions derived from "socket.error", exceptions from IOError, and exceptions from the SSL layer, which patches the
Some are retryable, some indicate that a different approach (different port, different protocol) should be tried, and some mean that some named resource doesn't exist. Programs need to make those distinctions reliably.
The most important distinction with sockets is "external network problem" vs. "local program program". To resolve this, I suggest a "NetworkException" in the exception hierarchy, with all the things that can go wrong due to conditions external to the local machine under that exception.
I'd suggest the following:
Then, programs that catch NetworkError could be sure of catching all network trouble conditions, but not local code bugs.
With these changes, any exception that's being caught now will still be caught.
I'd suggest doing 1) above immediately, since that's a clear bug, but the others need to be discussed.
agreed! the above suggestions sound good.
for number (3) if there are any places that raise OSError, that could lead to code upgrade headaches as the new NetworkError would not be a subclass of OSError. imho thats fine but others may disagree.
i am looking at implementing the immediate (1) and (2) as a starting point.
heres a patch against 2.6a0 svn HEAD implementing items 1 thru 6 (attached). I didn't look deeply to see if 4 is really implemented or not but the SSL errors were derived from socket.error so if they all use that as their base then they should be covered.
test suites pass.
Does the existing python SSL implementation allow it to be used over
fwiw, regarding this bug the last comment I heard from guido on the
On 8/25/07, Bill Janssen <email@example.com> wrote:
socket.error now inherits from IOError as of trunk r58067:
Change socket.error to inherit from IOError rather than being a stand
python-dev discussion here:
I chose IOError rather than EnvironmentError as the base class since
also a minor fix:
urllib2 - fix a couple places where IOError was raised rather than
test_urllib2net - replace bad ftp urls.