[Web-SIG] wsgi.fatal_errors

[Phillip J. Eby]

At 01:28 AM 9/2/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 11:15 PM 8/30/04 -0700, tony at lownds.com wrote:
>>>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.)
>
>This seems pretty reasonable.  How necessary is that optional body 
>argument?  Couldn't you just use the write argument or return an iterable?

The idea was to use it as a way to bypass non-exception middleware, without 
raising a fatal error.  OTOH, maybe Tony's approach is actually better.


>>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.  ;)
>
>It sounded good until then; now I don't know.  I think I'm -1 on that pun.

I get the humor of the second sentence; is the first sentence also humor, 
or is it serious?