[Web-SIG] Reviewing WSGI open issues, again...
Phillip J. Eby
pje at telecommunity.com
Thu Sep 9 22:31:56 CEST 2004
At 12:45 PM 9/9/04 -0700, tony at lownds.com wrote:
> > 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.
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"]
> > 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.
In that case, why not have the application simply not catch the error, and
let middleware do it?
I'm still confused as to how having a special exception helps.
>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.
Ah. ISTM that use case is effectively handled: use start_response()+return
[body] as I described above. If start_response fails, you're in basically
the same position you'd have been if you were raising a special
error. (I.e., your error wasn't going to get reported anyway.)
Of course, it could be argued that the server in that case doesn't have
anything of interest to log regarding the error. But that could be handled
by adding a 'body' argument to 'start_response' as I previously proposed.
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?
More information about the Web-SIG
mailing list