Socket exceptions aren't in the standard exception hierarchy

[John Nagle]

Here are three network-related exceptions. These
were caught by "except" with no exception type, because
none of the more specific exceptions matched. This
is what a traceback produced:
1. File "D:\Python24\li b\socket.py", line 295, in read
data = self._sock.recv (recv_size)
timeout: timed out

2. File "D:\Python24\li b\socket.py", line 295, in read
data = self._sock.recv (recv_size)
error: (10054, 'Connection reset by peer')

3. File "D:\Python24\li b\socket.py", line 317, in readline
data = recv(1)
IOError: [Errno socket error] timed out

For 1 and 2, those are errors that aren't in the
exception hierarchy. Looking at the C code for "socketmodule.c ",
it's clear that "socket.err or" doesn't inherit from any standard
exception class. See, in "init_socket()" :

socket_error = PyErr_NewExcept ion("socket.err or", NULL, NULL);

That first NULL should be some parent exception, maybe "IOError".
As it is, "socket.err or" is outside the standard exception hierarchy.
That's not too good.

Case #3, IOError, should have been caught by this:

except IOError, message: # I/O error

But it wasn't. The "IOError" fell through, was caught by the
next outer exception block, and was logged as a generic
error.

I can't find where in the Python socket module an "IOError"
could be raised. I would have expected "socket.timeout ".

Anyway, I need to know the full set of exceptions that can
be raised by sockets. Thanks.

John Nagle

[John Nagle]

On a related note, M2Crypto's exceptions are direct children
of Exception. If we add NetworkError, there will be a better
place to put them.

Currently, you have to catch, at least,

M2Crypto.SSL.Ch ecker.SSLVerifi cationError
M2Crypto.SSL.SS LError

both of which can be raised by socket operations if
M2Crypto is installed. I'm not sure what errors the
stock SSL module raises.

(I'm running stress tests on a dedicated machine in a colocation
facility. It's examining 11,000 known spam and malware sites right
now. This exercises the error handling, forcing many unusual cases
and logging the problems. That's why I'm discovering all these library
issues.)

John Nagle

Steve Holden wrote:

John Nagle wrote:

>Steve Holden wrote:

>>John Nagle wrote:

Steve Holden wrote:

John Nagle wrote:
[socket.error bug report]

>>All these notes should be included in the bug report, as I suspect
the module would benefit from additional clarity.

Done. See

[ 1706815 ] socket.error exceptions not subclass of StandardError

Also see

[ 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

for related but not identical problems in that area.

Thanks. At least this is less likely to be overlooked now.

regards
Steve