[Web-SIG] Reviewing WSGI open issues, again...
Phillip J. Eby
pje at telecommunity.com
Sat Sep 11 22:34:15 CEST 2004
At 10:38 AM 9/11/04 -0700, tony at lownds.com wrote:
> > 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?
Not if the call to start_response() was made from an error handler,
no. But I think it's acceptable to catch errors from normal (2-argument)
calls to start_response().
> > 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.
Good. We'll take the "third argument" approach, then. It's going to
expand the PEP quite a bit, but every error handling proposal so far was
going to do that. But this one handles your use case without adding much
overhead for the more common cases.
I can't believe we've managed to get away without having *any* special
environ keys for error handling or any custom exception classes (except
when you want to do something special, of course).
I'm going to try and get all the updates into the PEP this weekend,
hopefully before the next hurricane goes by. If it comes too close and we
lose power here, I don't expect we'll get it back for a week or two, as
there are too many crews still out fixing power outages from the *last*
Once all the pending updates are in, I think we'll be almost ready to
finalize the PEP, and we should plan on another posting to python-list and
python-dev, giving a finalization deadline and requesting that all
remaining change requests be submitted in the form of a patch.
Hm. Actually, that might be premature, since I recall we were planning to
get the HTTP/1.1 stuff in order first. Mark, how's that coming along? :)
More information about the Web-SIG