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

[tony at lownds.com]

>>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