Created on 2007-04-24 18:09 by nagle, last changed 2007-09-09 23:38 by gregory.p.smith. This issue is now closed.
|python-bug-1706815.diff||gregory.p.smith, 2007-07-04 03:25||patch implementing 1,2,3,5,6 and maybe 4|
|msg31874 - (view)||Author: John Nagle (nagle)||Date: 2007-04-24 18:09|
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.
|msg31875 - (view)||Author: John Nagle (nagle)||Date: 2007-04-24 18:12|
(See also PEP 352).
|msg31876 - (view)||Author: Gregory P. Smith (gregory.p.smith) *||Date: 2007-07-02 23:39|
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.
|msg31877 - (view)||Author: Gregory P. Smith (gregory.p.smith) *||Date: 2007-07-04 03:25|
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. File Added: python-bug-1706815.diff
|msg55301 - (view)||Author: Bill Janssen (janssen) *||Date: 2007-08-26 03:06|
It's not clear to me that having the SSL errors inherit from socket.error is a good idea. Many of them have nothing to do with the socket, but are errors in choice of cipher, certificate validation, etc.
|msg55302 - (view)||Author: Gregory P. Smith (gps)||Date: 2007-08-26 03:11|
Does the existing python SSL implementation allow it to be used over something other than a socket? If so then yes that makes sense, but otherwise its best to leave its inheritance from socket.error so that code that works when handed a regular socket can work over an SSL socket without knowing the difference. fwiw, regarding this bug the last comment I heard from guido on the python-dev list was that socket.error should at least be a subclass of EnvironmentError. I'm still a fan of having it a subclass of IOError myself for similar reason as above (things already written to use a file object as a stream could use a socket object and still handle errors properly; most code check for IOError rather than EnvironmentError if for no reason other than IOError is easier to type and easier to read and understand what it means) On 8/25/07, Bill Janssen <firstname.lastname@example.org> wrote: > > Bill Janssen added the comment: > > It's not clear to me that having the SSL errors inherit from socket.error > is a good idea. Many of them have nothing to do with the socket, but are > errors in choice of cipher, certificate validation, etc. > > ---------- > nosy: +janssen > > _____________________________________ > Tracker <email@example.com> > <http://bugs.python.org/issue1706815> > _____________________________________ >
|msg55770 - (view)||Author: Gregory P. Smith (gregory.p.smith) *||Date: 2007-09-09 23:38|
socket.error now inherits from IOError as of trunk r58067: Change socket.error to inherit from IOError rather than being a stand alone class. This addresses the primary concern in http://bugs.python.org/issue1706815 python-dev discussion here: http://mail.python.org/pipermail/python-dev/2007-July/073749.html I chose IOError rather than EnvironmentError as the base class since socket objects are often used as transparent duck typed file objects in code already prepared to deal with IOError exceptions. also a minor fix: urllib2 - fix a couple places where IOError was raised rather than URLError. for better or worse, URLError already inherits from IOError so this won't break any existing code. test_urllib2net - replace bad ftp urls.
|2007-09-09 23:38:26||gregory.p.smith||set||status: open -> closed|
nosy: - gps
messages: + msg55770
messages: + msg55302
messages: + msg55301