[Web-SIG] Reviewing WSGI open issues, again...
tony at lownds.com
tony at lownds.com
Sat Sep 11 19:38:55 CEST 2004
>>Servers need additional logic to try and support calling start_response
>>twice.
>
> They'll need it in any case. What are the odds that all errors will occur
> before start_response happens?
>
Not good, hence the requirement that servers support re-starting the
response. With exception handling, they just need a little bit of logic to
decide whether to send the payload of the exception. They don't HAVE to
support re-starting the response. Hmm, except then there would be a lot of
"200 Ok" responses that actually ended in an error.
>
>>Calling start_response again could still be an error for the
>>application, masking the error.
>
> True. This is probably the strongest argument for having a special
> exception. That is, that an exception-in-progress could be masked by the
> error of calling start_response again. OTOH, there's always:
>
> try:
> try:
> t,v,tb = sys.exc_info()
> start_response("500 Error occurred", headers)
> except:
> raise t,v,tb # reraise the original
> else:
> return ["error body here"]
> finally:
> t = v = tb = None
>
> but admittedly, this is "guru-level" coding. OTOH, we could simply have
> an
> optional third argument to start_response:
>
> start_response(status,headers,sys.exc_info())
>
> the idea being that 'start_response' should reraise the exc_info tuple (or
> some private exception type) if the response has already been started. It
> can also optionally log the error information.
>
> Note that this also allows middleware to trivially intercept error reports
> by overriding start_response. If it decides to handle the error itself,
> the middleware can simply throw an exception that it then catches as the
> app aborts.
>
That reasonably handles the exception case. Applications and middleware
should never catch exceptions from start_response then, correct?
> I think that we can meet this use case without a server-provided exception
> class; the server (or middleware) just needs to know that you're starting
> an error response, and what the error is. Adding an argument to
> start_response seems like a good, clean way to do this, and it looks easy
> to use/implement on all sides. What do you think?
>
I'm beginning to think that re-startability is important. It makes it much
less likely that a successful HTTP code is returned when the application
actually broke. Given that, I don't
see much of an advantage to the exception.
-Tony
More information about the Web-SIG
mailing list