Bugs item #1706815, was opened at 2007-04-24 18:09
Message generated for change (Comment added) made by nagle
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1706815&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.error exceptions not subclass of StandardError
Initial Comment:
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
[ 1019808 ] wrong socket error returned
[ 1571878 ] Improvements to socket module exceptions
[ 708927 ] socket timeouts produce wrong errors in win32
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
sockets module when loaded. These are non-bug exceptions; that is, the problem
is out in the network, external to the program.
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:
1. Add "NetworkError" under "IOError" in the exception hierarchy.
2. Put the existing "socket.error" under "NetworkError". Since "socket.error"
needs to be reparented anyway (it's currently a direct descendant of
"Exception") this provides a good place for it.
3. Find any places where the socket module can raise IOError or OSError due to
an external network condition, and make them raise something under NetworkError
instead. Code that catches IOError will still work.
4. Put all errors in the various SSL modules (SSLError, etc.) which can be
raised due to external network conditions under "NetworkError"
5. Move "urllib2.URLError", which is currently under IOError, down a level
under NetworkError.
6. Move the misc. errors from "urllib", like "ContentTooShortError", which are
currently under IOError, down a level under NetworkError.
7. URL translation errors from the IDNA (Unicode URL encoding) module probably
should raise an error similar to that for an incorrect URL, rather than raising
a UnicodeError.
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.
----------------------------------------------------------------------
>Comment By: John Nagle (nagle)
Date: 2007-04-24 18:12
Message:
Logged In: YES
user_id=5571
Originator: YES
(See also PEP 352).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1706815&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
