On 8/21/2011 2:26 PM, Paul Rubin wrote:
Steven D'Aprano<steve+comp.lang.pyt...@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
--
http://mail.python.org/mailman/listinfo/python-list
