[Web-SIG] wsgi.fatal_errors

[Phillip J. Eby]

At 11:15 PM 8/30/04 -0700, tony at lownds.com wrote:
> > Here are some changes I've proposed in the last few days to resolve issues
> > people brought up, but which I haven't gotten much feedback on:
> >
> > * 'wsgi.fatal_errors' key for exceptions that apps and middleware
> > shouldn't
> > trap
> >
>
>What about defining an exception class that applications can raise with an
>HTML payload, which servers are supposed to send the to the client?
>Middleware should be free to alter the payload as much as they like. The
>server should not send the payload when content-type is not html.
>
>By using exceptions as a backchannel, the application and middleware do
>not have to keep track of the state to sanely handle an error.

Interesting.  But I think you've just given me an idea for a possibly 
simpler way to do this, with some other advantages.

Suppose that instead of 'start_response(status,headers)' we had 
'set_response(status,headers,body=None)'.  And the difference would be that 
our 'set_response' does nothing until/unless you call write() or yield a 
result from the return iterable.  Therefore, you could call 'set_response' 
multiple times, with only the last such call taking effect.  (If you supply 
a non-None 'body', then calling write() or returning an iterable is an error.)

Now consider error handling middleware: it simply calls 
'set_response(error_status,error_headers,error_body)', and returns None.

At this point, we've isolated the complexity to exist only for streaming 
responses once the first body chunk has been generated.  We can handle this 
by making a call to 'set_response()' a fatal error if a body chunk has been 
generated.  Thus, no special handling is needed by an exception handler: it 
just tries to do 'set_response()', and allows the fatal error (if any) to 
propagate.  Now, the server can catch the fatal error and deal with it.

I think this will let us keep all of the complications in the server, where 
they always have to exist, no matter what else we do.  Exception-handling 
middleware is then delightfully simple.

On the other hand, output-transforming middleware becomes somewhat more 
complex, as it would now have three output sources to transform (body param 
to set_response(), write(), and output iterable).

This is a fairly significant change to the spec, that introduces lots of 
new angles to cover.  But, I think it could be an "exceptionally" clean 
solution to the problem.  ;)