Dennis Lee Bieber wrote: > On Sun, 22 Apr 2007 23:20:25 -0700, John Nagle <[EMAIL PROTECTED]> > 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 -- http://mail.python.org/mailman/listinfo/python-list