Socket exceptions aren't in the standard exception hierarchy

John Nagle nagle at animats.com
Mon Apr 23 13:21:12 EDT 2007


Dennis Lee Bieber wrote:
> On Sun, 22 Apr 2007 23:20:25 -0700, John Nagle <nagle at animats.com>
> declaimed the following in comp.lang.python:
> 
> 
>>2. File "D:\Python24\lib\socket.py", line 295, in read
>>data = self._sock.recv(recv_size)
>>error: (10054, 'Connection reset by peer')
>>
> 
> 	That looks like M$ Windows version of UNIX/Linux error number 54
> (pretty much all Windows socket errors are UNIX number+10000)
> 
> 	Errors coming from Windows may not be mapped to specific Python
> exceptions, but rather to some general error conditions. {hypothesis} As
> such, the Windows errors may not match what UNIX/Linux report.

     Actually, that's not what's happening. The socket module is
explicitly raising "socket.error" in C code.  It's not an OSError or
a WindowsError, although the text makes it look like one.

     The problem is not that socket errors aren't entirely portable.
It's that they're not even in the Python exception hierarchy.
See "http://docs.python.org/lib/module-exceptions.html".
They have their own hierarchy, which starts at "socket.error".
All built-in exceptions were supposed to be converted to the
standard exception hierarchy back before Python 2.0, but these
weren't.

     Either they should be under IOError, or there should be
"NetworkError" under EnvironmentError, and they should be under
that.  "NetworkError", alongside IOError in the hierarchy,
would be useful.  All the things that go wrong in networking
belong under there.  Socket-level errors, SSL/TLS-level errors,
and HTTP/FTP/etc. level errors all belong under NetworkError.

     This has to be fixed before PEP 352, when the exception
hierarchy is enforced, or the socket exceptions won't even work
right.

				John Nagle



More information about the Python-list mailing list