I opened ticket #12250 for this exact reason a while ago. It's currently design decision needed. I'm still in favor of giving middleware a chance to handle errors raised by middleware.
https://code.djangoproject.com/ticket/12250 Regards, Michael On Sep 1, 11:48 am, Tom Evans <tevans...@googlemail.com> wrote: > 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.
