open() and EOFError

[Roy Smith]

In article <53bae1db$0$29995$c3e8da3$5496439d at news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:


> While I agree with the general idea that try blocks should be as narrow 
> *as reasonable*, they shouldn't be as narrow *as possible* since one can 
> start guarding against unreasonable things.

I'm more willing to accept multi-statement try blocks with multiple 
except clauses when the things you're catching are very specific:

try:
    foo.quack()
    bar.roar()
except Foo.QuackError:
    print "OMG, can't quack"
except Bar.RoarError:
    print "Yowza"

If you're catching generic things like IOError or ValueError, it's more 
likely for there to be some code path you didn't expect.

> The thing is, even if you catch these bizarre things, what are you going 
> to do with them? If you can't do anything about it, there's no point 
> catching the exception -- never catch anything you can't recover from, or 
> otherwise handle. Just treat it as a fatal error and let it cause a 
> traceback.

That I agree with.  Of course, sometimes you do want to catch 
*everything*.  For example, in something like a web server, you want to 
have something like

try:
   do_request()
except Exception:
   handle_exception()
except:
   # WTF?  This should never happen, but deal with it anyway
   handle_exception()

way up at the top.  Our handle_exception() logs a stack trace and 
returns a 500-something HTTP response.  The alternative is to have the 
web server exit, which would be a Bad Thing.  Well, actually, if that 
happened, the gunicorn master process would catch that a worker exited 
and restart it, but that would be slow.  And if gunicorn exited, then 
upstart would catch that, and restart gunicorn :-)