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

[Phillip J. Eby]

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?