Hi all
Currently, if a view throws an exception, the middleware classes that
have a process_exception method will be called in reverse order to see
if one of them can handle it and return a valid response before
django's default exception handling takes over.
This doesn't hold true for middleware classes themselves - any
exception raised from a middleware's process_{request,view,response}
is immediately handled by django's default exception handling, and
there is no way of handling that exception more cleanly.
The use case I saw for this was for a series of exceptions that
middleware classes could raise, which would then be handled by another
piece of middleware. As an example, my project has a bunch of
automatic authenticators - IP based, SAML based, crufty tokens
produced by Lotus Notes - but they failures in all of them should be
handled the same. Raising a generic exception in the appropriate
middleware, and then handling it in another middleware class seemed a
nice clean way of doing this, I was disappointed when I read
core/handlers/base.py
It wouldn't be tricky to change this so that exceptions raised from
middleware can be handled by middleware, but obviously this would be a
not inconsequential change in behaviour..
Thoughts?
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
