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

[tony at lownds.com]

> At 11:32 AM 9/9/04 -0700, tony at lownds.com wrote:
>
>>I still like the idea of having an exception that servers will always
>>catch and send back to the user.
>
> Currently, isn't that *every* exception?  I'm making the assumption that
> the server will want to log and display every non-fatal error.  (Except
> those occurring after the headers are sent, which can only be logged in
> the
> general case.)
>

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.

>
>>If an application doesn't know whether a
>>server can display an error page, it will tend to include it's own
>>error-displaying logic (made simpler by the start_response() above). But,
>>if applications take care of displaying those exceptions, then exception
>>catching middleware won't really be useful for those applications.
>
> This seems circular to me: if the application throws an error that's
> actually an application-defined error message, then why is middleware
> going
> to be *useful* here?
>
> You must have some other use case in mind besides the middleware
> presenting
> a friendly message, since presumably the application can produce a
> friendlier message (at least in the sense of being specific to the app and
> looking like the app).  Could you elaborate on your use case?
>

Middleware can use the exception to provide side-effects, like notifying
developers, or displaying diagnostics to certain IPs.

Mainly the use case is that raising an exception with an HTML page is less
error prone for applications and middleware than invoking write from
within an except clause. The server can decide whether it will be able to
send out the error page, rather than the application or middleware having
to try and figure out if it can successfully start a response from
scratch.

> OTOH, the purpose of fatal_errors is to allow the *app* to know that it's
> pointless to go on, and that it *should* abort.  This still seems somewhat
> useful to me, although it could also be argued that virtually *any*
> exception raised by start_response() and write() should be considered
> fatal.
>

Yes, I would have thought so.

>>And servers can't rely on applications adhering to the
>>rules in the specs.
>
> I'm not sure what you mean here, but maybe it's what I just said
> above?  (about apps maybe being broken in their handling of fatal_errors).
>
>

Yep

-Tony