Opened 9 years ago
Closed 9 years ago
#25697 closed Cleanup/optimization (fixed)
Default error views shouldn't silence TemplateDoesNotExist errors if a custom template name was specified
Reported by: | Simon Charette | Owned by: | Iacopo Spalletti |
---|---|---|---|
Component: | Generic views | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Default error views attempt to load a template from a default name and fallback to a string value if a TemplateDoesNotExist
error is raised in the process.
This behavior should be altered to actually raise the error if a custom template_name
is specified.
The affected views are:
django.views.defaults.page_not_found
django.views.defaults.server_error
django.views.defaults.bad_request
django.views.defaults.permission_denied
Note that the views were identified during a preliminary search and it's possible this pattern is used elsewhere in the Django code base.
We should consider deprecating this behavior instead of simply turning it on since it's slightly backward incompatible.
Thanks to Raphael Michel at #DUTH for helping identifying this issue.
Change History (10)
comment:1 by , 9 years ago
Description: | modified (diff) |
---|
comment:2 by , 9 years ago
comment:3 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 9 years ago
Has patch: | set |
---|
comment:5 by , 9 years ago
I'm lukewarm on deprecations (since it adds a lot of overhead for us) instead of making minor backwards incompatible changes in cases like this where it seems to simply delay revealing probable errors in user code. A similar case was select_related()
field name validation where we made a backwards-incompatible change -- Carl, I believe you said you thought that should have gone through a deprecation. Just wanted to bring it up for discussion so I can crystallize my thinking around changes like this. Thanks!
comment:6 by , 9 years ago
Easy pickings: | unset |
---|---|
Patch needs improvement: | set |
No one indicated an opposition on the mailing list to skipping a deprecation and making this a backwards incompatible change.
comment:7 by , 9 years ago
Ok, I'll change the PR to avoid the deprecation period and edit the changelog the reflect this change
comment:8 by , 9 years ago
Patch needs improvement: | unset |
---|
comment:9 by , 9 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Yes, I think we'd need a deprecation path here where initially we raise a PendingDeprecationWarning on an explicitly-specified nonexistent template, then a DeprecationWarning, and then finally switch to raising the TemplateNotFound.