In <254eac4d-ce19-4af9-8c6a-5be8e7b0f...@u16g2000pru.googlegroups.com> Sean
DiZazzo <half.ital...@gmail.com> writes:
>On Sep 18, 11:54=A0am, kj <no.em...@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
--
http://mail.python.org/mailman/listinfo/python-list
