Scanning a file

Steven D'Aprano steve at REMOVEMEcyber.com.au
Mon Oct 31 03:08:27 CET 2005


Alex Martelli wrote:

> Steven D'Aprano <steve at REMOVETHIScyber.com.au> wrote:
>    ...
> 
>>>No.  But if you get a totally unexpected exception, 
>>
>>I'm more concerned about getting an expected exception -- or more
>>accurately, *missing* an expected exception. Matching on Exception is too
>>high. EOFError will probably need to be handled separately, since it often
>>isn't an error at all, just a change of state. IOError is the bad one.
>>What else can go wrong?
> 
> 
> Lots of things, but not ones you should WISH your application to
> survive.

[snip]

> Sure, that's why you catch IOError, which covers these _expected_ cases
> (or, if you want to be a bit wider, maybe OSError) AND check its errno
> attribute to ensure you haven't mistakenly caught something you did NOT
> in fact expect (and thus can't really handle), to use a bare raise
> statement to re-raise the "accidentally caught" exception if needed.

Ah, that's precisely the answer I was looking for: 
IOError and OSError, and then check the errno. 
Excellent: thanks for that.

> But if something goes wrong that you had NOT anticipated, just log as
> much info as you can for the postmortem, give nice diagnostics to the
> user if you wish, and do NOT keep processing -- and for these
> diagnostic-only purposes, use sys.excepthook, not a slew of try/except
> all over your application making it crufty and unmaintainable.

Agreed -- I never intended people to draw the 
conclusion that every line, or even every logical block 
of lines, should be wrapped in try/except.


-- 
Steven.




More information about the Python-list mailing list