#17828 closed Cleanup/optimization (fixed)
Admin should not handle IncorrectLookupParameters if settings.DEBUG is set
Reported by: | Owned by: | Chris Adams | |
---|---|---|---|
Component: | contrib.admin | Version: | 1.4-beta-1 |
Severity: | Release blocker | Keywords: | |
Cc: | chris@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
Right now its difficult to debug exceptions raised in ListFilter code which raises an exception because the exception will be wrapped in an IncorrectLookupParameters exception, then caught by ModelAdmin.changelist_view which renders an uninformative invalid_setup.html template.
I propose adding in the except IncorrectLookupParameters block the following:
if settings.DEBUG: raise
So that the main django exception handler can render the much more informative exception template. I've tested this and it seems to work fine.
Attachments (4)
Change History (16)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Triage Stage: | Unreviewed → Accepted |
---|
I got a totally absurd error page while working on #17830; I suppose it's because of this bug.
comment:3 by , 13 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 13 years ago
Cc: | added |
---|---|
Easy pickings: | set |
Has patch: | set |
Type: | Uncategorized → Cleanup/optimization |
I have a basic patch here which adds the settings.DEBUG check and some tests:
https://github.com/acdha/django/compare/17828-debug-IncorrectLookupParameters
It seems like there should be a logging.exception
call in the non-DEBUG path so sysadmins have an easy way to learn about problems.
by , 13 years ago
Attachment: | 17828-debug-IncorrectLookupParameters.patch added |
---|
GitHub-generated patch
comment:6 by , 13 years ago
Severity: | Normal → Release blocker |
---|
So it appears that the problem is in fact deeper. When a list filter's queryset() method fails, it should fail loudly instead of getting swallowed by a IncorrectLookupParameters
exception (which then triggers a redirection, which in turn leads to the display of this confusing 'Database Error` page). This problem was in fact introduced by... me, in [16705], where I attempted to fix a regression spotted in #16716. The attached patch fixes that regression properly and also prevents this confusing error to be displayed.
Marking as a release blocker since it's a bug in a new feature.
by , 13 years ago
Attachment: | 17828.listfilter-proper-error-handling.diff added |
---|
follow-up: 8 comment:7 by , 13 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Looks good to me in general, I wish we didn't have to catch all exceptions though.
comment:8 by , 13 years ago
Replying to jezdez:
Looks good to me in general, I wish we didn't have to catch all exceptions though.
I share that distaste – perhaps a second round which only catches the ORM exceptions?
by , 13 years ago
Attachment: | 17828.listfilter-proper-error-handling.2.diff added |
---|
by , 13 years ago
Attachment: | 17828.listfilter-proper-error-handling.3.diff added |
---|
Without naked except
comment:9 by , 13 years ago
Good catch. There was actually no need for a naked except there, so I've corrected that in the new patch. I'll push it unless you spot something else.
comment:11 by , 13 years ago
So, why was my first comment apparently not taken into consideration? Now that I think about it, every naked except which raises a new exception 'should' as a matter of policy include the stack trace from the previous exception. Are there any reasons why this should not be done? Just the exception object without the previous stack turns debugging into a spin of the roulette wheel. I prefer to have a reasonable chance of debugging exceptions.
comment:12 by , 13 years ago
After talking with Julien, I realize I was partly wrong, what I wanted is done by this fix. And I need to file a new issue about this naked except.
Also as an optional addon to this fix, the traceback should preserve the original exception's traceback. I've implemented this by modifying the raise statement in admin.views.main.ChangeList.get_query_set to be raise IncorrectLookupParameters, IncorrectLookupParameters(e), sys.exc_info()[2]