Alex Martelli wrote: > Steven D'Aprano <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
