[Web-SIG] Reviewing WSGI open issues, again...

[tony at lownds.com]

>>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