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

[Phillip J. Eby]

At 09:24 AM 9/11/04 -0700, tony at lownds.com wrote:
> >>No, I mean that the server will send back a document that was sent as
> >> part
> >>of the exception, not a document derived from the exception and/or
> >>traceback. It is a mechanism that applications can rely on to get an
> >> error
> >>notice to the user.
> >
> > I'm still not seeing how this is different from the application simply
> > catching the exception at its highest level, and doing:
> >
> >        start_response("500 Error occurred",
> > [('Content-type','text/plain')])
> >        return ["error body here"]
> >
> >
>
>
>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?


>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 code doesn't work from the iterator.

It only would have worked if it was in the first iteration, anyway.  The 
server is probably in the best position to attempt recovery following the 
first iteration.  However, in most cases where such code would *be* in the 
iterator, it's likely a generator that can simply yield the error 
body.  Using the third-argument strategy above, it's going to get an error 
if it wouldn't work.



> > Let me see if I understand your actual use case...  you want to be able to
> > write an application that, although it handles its own errors, also gives
> > users the option of placing error-handling middleware over it to change
> > how
> > its errors are rendered, logged, etc.  And, you want that mechanism to be
> > based on Python exception information (type, value, traceback) rather than
> > on HTTP information (status, headers, content).  Finally, you want this to
> > be unconditionally available, rather than having to first check whether
> > the
> > exception handling middleware is installed.  Is this correct?
>
>Yes, with the addition of a server-provided exception class that holds the
>error document payload.

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?