Granularity of OSError

kj at
Fri Sep 18 21:47:59 CEST 2009

In <254eac4d-ce19-4af9-8c6a-5be8e7b0fffa at> Sean DiZazzo <half.italian at> writes:

>On Sep 18, 11:54=A0am, kj <no.em... at> wrote:
>> I've often come across the idea that good Python style deals with
>> potential errors using an EAFP ("easier to ask forgiveness than
>> permission") strategy rather than a LBYL ("look before you leap")
>> strategy.
>> For example, LBYL would look like this:
>> if os.path.isfile(some_file):
>> =A0 =A0 os.unlink(some_file)
>> In contrast, EAFP would look like this:
>> try:
>> =A0 =A0 os.unlink(some_file)
>> except OSError:
>> =A0 =A0 pass
>> But, as written, the EAFP code above is not satisfactory, because
>> there can be OSError's triggered for reasons other than the
>> non-existence of the regular file some_file.
>> What one needs is a finer granularity of exception, mapping to
>> exactly the error that one is guarding against.
>> Is there a standard approach to refining the granularity of exceptions
>> such as OSError? =A0The only approach I can think of is to somehow
>> parse the error string (assuming is available) to determine whether
>> the exception is indeed of the specific kind we're trying to catch.
>> But this strikes me as grossly inelegant. =A0Is there a better way?
>> (BTW, the problem is generic, because client code has no control
>> over the specificity of the exceptions raised by a library module.
>> If these exceptions turn out to be too broad, client code has to
>> somehow deal with this reality, at least in the short term.)
>> TIA!
>> kynn

>You can access the exception object which gives you greater detail.

>    os.unlink(some_file)
>except OSError, e:
>    print e.errno
>    print e.strerror

>    if e.errno =3D=3D 2:
>        pass
>    else:
>        raise

>If it's the error you are looking for, handle it, or else raise.

Thanks, that's very handy. 


More information about the Python-list mailing list