Granularity of OSError

[kj]

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

>On Sep 18, 11:54=A0am, kj <no.em... at please.post> 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.

>try:
>    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. 

kynn