try... except with unknown error types

Steven D'Aprano steve+comp.lang.python at pearwood.info
Mon Aug 22 06:01:55 CEST 2011


On Mon, 22 Aug 2011 10:41 am Chris Angelico wrote:

> On Mon, Aug 22, 2011 at 1:30 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> /s/would/should/
>>
>> I don't see why you expect this, when *existing* network-related failures
>> aren't
> 
> Ehh, granted. Definitely a case of "should". But certainly, there
> won't be an infinite number of new exceptions invented; most of the
> runtime issues you'll have will fall into a fairly small number of
> exception types (either by subclassing or by parameters eg errno).

Er, you can't know that either.

Except that all exceptions must be rooted at BaseException, there *can* be
an infinite number of new exception types invented. Or functions could
raise unexpected, but known, exceptions, whether built-in or not.

Of course, the set of hypothetical exceptions that could theoretically be
raised is much, much bigger than the set of exceptions which you can
realistically expect to see, especially if you limit yourself to those that
don't leave you wondering about the sanity of the developer ("WTF? Why is
x+1 raising HTTPBadGatewayError?"). But still, as a general rule you should
not be surprised to see any of:

AttributeError
TypeError
ValueError
(and likely others)

The more important question is, if you get an exception, any exception, is
that a bug in the function you are calling, a bug in your calling code (you
supplied a bad argument), or an expected result that you should catch and
work around?


-- 
Steven




More information about the Python-list mailing list