[Web-SIG] Reviewing WSGI open issues, again...
tony at lownds.com
tony at lownds.com
Sat Sep 11 18:24:00 CEST 2004
>>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. Calling start_response again could still be an error for the
application, masking the error. That code doesn't work from the iterator.
> 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.
-Tony
More information about the Web-SIG
mailing list