[Web-SIG] WSGI start_response exc_info argument

Ian Bicking ianb at colorstudy.com
Wed Mar 30 21:21:38 CEST 2005


Phillip J. Eby wrote:
>> It really should capture the headers, and maybe buffer them itself (in 
>> which case it would also have to intercept the writer), so that it can 
>> deal more gracefully with a case where content type is set or 
>> something.  But all that annoying stuff is better kept to this one 
>> piece of middleware, instead of making everything more difficult with 
>> that extra argument to start_response.
> 
> 
> Um, the argument is *precisely* there so you don't need all of that! Try 
> this:

But I don't mind all of that, because it is only contained in the error 
catching middleware and no where else.  I have other middleware that 
overrides start_response, and don't want to bother with all the exc_info 
in that case.  And a lot of the logic -- like trying to show errors even 
when there's been a partial response -- is just work, there's no way to 
get around it.

> 
> def __call__(self, environ, start_response):
>     try:
>         app_iter = self.application(environ, detect_start_response)
>     except:
>         start_response('500 Internal Server Error',
>                                [('content-type', 'text/html')], 
> sys.exc_info())
>         # etc...
> 
> No need to track the startedness here, because the upstream 
> start_response will reraise the error if you've already started, thus 
> breaking out of the middleware and getting back to the calling server.



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


More information about the Web-SIG mailing list