On 9 heinä, 19:59, Don Spaulding <[email protected]> wrote: > 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/bas... > session.save() bug is later caught > by:https://github.com/django/django/blob/master/django/core/handlers/bas... > > So, am I way off base with this? Is it worth opening a separate ticket?
I have updated the branch [https://github.com/akaariai/django/tree/ ticket_3881], I think it now has all the necessary doc changes. If somebody is kind enough to double-check the patch, that would be great. If that somebody is a committer, committing the code at the same time is fine for me. If no further feedback, I will commit the patch in a day or two. As for showing the original exception if a middleware generates an exception, something along those lines sounds good. However, hiding the middleware exception can be as bad as hiding the original exception. So, maybe there should be a message telling that there was an exception in the view, and then an exception in the middleware, too. The latest (that is, the middleware's exception) should be shown in full, as that is the first thing that should be debugged. There is no way to get the middleware exception's traceback if that is not the default, but one can get the original exception by just disabling the problematic middleware. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. 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.
