On Saturday, July 7, 2012 3:46:14 AM UTC-5, Florian Apolloner wrote: > > On Friday, July 6, 2012 12:02:56 AM UTC+2, Luke Plant wrote: >> >> I agree it should be changed, and I would regard it as a bug fix, but >> make a note of it in the 1.5 release notes nonetheless. >> > > +1 > > Cheers, > Florian >
I was recently bit by this when I had an exception being thrown for a non-existent column. Instead of seeing the psycopg2 exception that I would expect, I was continually seeing the "current transaction is aborted" exception. Since I had figured out what the initial exception was, I finally dug in a little bit to see why I wasn't getting the traceback for it. I expected to find some middleware of my own creation catching (and swallowing) the initial exception. However, I ended up tracing my view and was surprised to see the exception bubbled all the way up to django/core/handlers/base.py. I found this ticket and wondered if the solution in it was the right approach, or more accurately, whether there are two problems worth fixing here. Specifically, I'm wondering why, when given an unhandled exception in the view callback and then another one in a response middleware, Django should choose to display the middleware exception. Obviously, the current behavior of always running response middleware even in the face of an unhandled exception is intended. I propose that Django keep a reference to the original uncaught exception, and return that one to the client even if a response middleware throws an uncaught exception as well. I'm much less concerned with whether or not the session.save() succeeds or fails than I am with what the original exception was. If I'm told what the original exception was, I can stop aborting transactions, and the session.save() fixes itself. It may still be worth it to guard the call to session.save() with a connection.can_run_queries() conditional, but to me, that seems less important than having BaseHandler.get_response() show me the debug 500 page on the "right" exception. First exception is caught by: https://github.com/django/django/blob/master/django/core/handlers/base.py#L178 session.save() bug is later caught by: https://github.com/django/django/blob/master/django/core/handlers/base.py#L192 So, am I way off base with this? Is it worth opening a separate ticket? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/c3hSfBTkwSoJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
