try... except with unknown error types

[Terry Reedy]

On 8/21/2011 2:26 PM, Paul Rubin wrote:
> Steven D'Aprano<steve+comp.lang.python at pearwood.info>  writes:
>>> But there's no way to know what that minimum is.  Python libraries throw
>>> all sorts of exceptions that their documentation doesn't mention.
>>
>> Yes, you're absolutely correct. But it's also irrelevant. Most of those
>> exceptions should not be caught, even if you know what they are, because
>> they represent either bugs that should be fixed, or bad data which should
>> raise an exception. A bare except, or except Exception, is hardly ever the
>> right approach.
>
> I'm not sure what to do instead.  The exceptions I'm currently dealing
> with happen when certain network operations go wrong (e.g. network or
> remote host is down, connection fails, etc.)  The remedy in each case is
> to catch the exception, log the error, and try the operation again
> later.  But there's no guaranteed-to-be-complete list in the Python docs
> of all the exceptions that can be thrown.  A new and surprising mode of
> network failure can lead to an unhandled exception, unless you catch
> everything.

I would expect that catching socket.error (or even IOError) should catch 
all of those.

"exception socket.error
A subclass of IOError, this exception is raised for socket-related 
errors. It is recommended that you inspect its errno attribute to 
discriminate between different kinds of errors."

> It's a retail application that would cause some business disruption and
> a pissed off customer if the program went down.  Also it's in an
> embedded box on a customer site.  It's not in Antarctica or anything
> like that, but it's a few towns over, and someone would have to drive
> there (probably through heavy traffic) if something went wrong that
> power cycling the box couldn't fix.


-- 
Terry Jan Reedy