Robert Brewer wrote: > Ian Bicking wrote: >> http://wsgi.org/wsgi/Specifications/throw_errors >> ... >> Problems >> -------- >> >> * In theory an application may know better how to format an error >> response than the middleware exception catcher. Of course, an >> application can ignore ``x-wsgiorg.throw_errors`` if it thinks it is >> best (or if it has been explicitly configured to do so). > > I'm not sure I see the benefits of declaring this in the WSGI environ. > If you're already conceding that each consumer of this may be configured > to ignore it, that's duplicated effort. That is, instead of having a > simple configuration item per app: > > throw_errors = True > > ...I now have to present the deployer with a more-confusing and more > tightly-coupled option: > > ignore_wsgiorg_throw_errors = True > > If both the protocol and my app's API are now more complicated, what > have we gained?
I concede someone, somewhere might want to ignore the environ key. I've never wanted to do so myself. There's no good reason I can think of that any exception catcher I've written would ignore that environ key, because they don't add any particular value when tied more closely to the application. I can imagine someone, somewhere might write such an exception catcher that has some added value. And they might then add this configuration option (maybe phrased as "force_error_catching"). The specified (and presumably default) behavior applies to most cases, especially cases where the developer isn't entirely aware of the relationship of the application to its exception catcher, and of the test framework to the application. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
