Scanning a file
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
> 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.
More information about the Python-list