In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Alex Martelli) wrote:
> Harlin Seritt <[EMAIL PROTECTED]> wrote: > > > except socket.error: > > code goes here... > > > > Of course, though, these are two separate error messages under the same > > error handler though. I've tried: > > > > except socket.error, (10061, 'Connection refused'): > > and > > except (socket.error, 10061, 'Connection refused'): > > > > to no avail. What do I need to do to catch each one specifically? > > what I've done in such situations is > > except socket.error, e: > if e.errno == 10061: > ... > elif e.errno == 10060: > ... > else: > raise This is not portable, however. I'm guessing you're running on Windows, because the 10061 corresponds to: {WSAECONNREFUSED, "Connection refused"}, in Python-2.3.4/Modules/socketmodule.c:set_error(). See http://tinyurl.com/gth2 for more winsock error codes. It would be nice if the socket library threw more specific exceptions, but given that the underlying operating systems export such a wide variety of system-level errors, it's not clear it's feasible, even if one wanted to put the effort into it. Which brings us back to having to resort to unportable tricks like the above to decipher the inner meaning. But, the real question is, WHY do you want to differentiate between these? The only reason to want to know which kind of connection failure you got is because you want to do something different on some errors. What are you going to do differently when you get one of these? socket.error: (10061, 'Connection refused') socket.error: (10060, 'Operation timed out') Operationally, they're pretty much the same. One might guess that on a timeout, it's worth waiting a while and trying again, but it may be worth doing that on a refusal as well. Perhaps you caught the remote system right after a reboot when the kernel network code is up, but the particular service you're trying to connect to hasn't started yet? Perhaps there's some kind of load-limiting in use? Perhaps the remote system is validating connections by reverse DNS checks, and inconsistent DNS caches are causing some connections to fail while others succeed? Any of these might deserve a retry. -- http://mail.python.org/mailman/listinfo/python-list