[Web-SIG] Other kinds of environment variables

[Ian Bicking]

Phillip J. Eby wrote:
>>> When I think of middleware, I can think of many things like this.  In 
>>> most cases, I'd add a key, and if the key wasn't present I'd know it 
>>> was false.  But it can be odd.  Say I have a middleware that catches 
>>> exceptions, because that's my one example at the moment.  If it is 
>>> present, it would be nice if other applications didn't catch 
>>> exceptions, and let them propagate all the way up.  So, the 
>>> application looks for 
>>> environ.get('ianb_middleware.exception_catcher')?  That's weird, 
>>> because someone else comes along and makes their own exception 
>>> catcher that works like mine; what key do they use?  It would be nice 
>>> if we used the same key.
> 
> 
> I'm somewhat negative on this concept; to me an application should be 
> responsible for catching its own exceptions, or require a middleware 
> wrapping for it.  The server/gateway *has* to be responsible for 
> catching any otherwise uncaught exceptions.  I don't really get the 
> concept of wanting to *not* catch exceptions.  If you have a two-layer 
> model (app+exception catcher), just put the handler you want to use in 
> place as middleware.  If the app has its own exception handling, surely 
> it knows better how to handle the exception than anything else, so why 
> change?

Generally the app doesn't know how to best handle unexpected exceptions. 
  There's no "right" way to handle unexpected exceptions, because they 
are unexpected.  Handing unexpected exceptions is usually 
installation-specific.  Imagining a heterogeneous setup with multiple 
applications, it would be annoying to configure each application when 
you could group them, and to deal with some applications having poor 
support for debugging vs. others.  E.g., a good exception catcher will 
log lots of information for post-mortem debugging, notify the 
appropriate person, etc.  A poor exception catcher just prints out the 
traceback for the user.  Blech.

Certainly this could also be done as a library.  Maybe that's better, 
but I still like the idea of centralizing it.  I don't think it's so bad.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org