Opened 13 years ago
Closed 12 years ago
#18155 closed Bug (invalid)
Undocumented changes, indecision, in template fail silently exception handling
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Template system | Version: | 1.4 |
Severity: | Normal | Keywords: | template fail silently |
Cc: | vim@… | Triage Stage: | Design decision needed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I realize many tickets have already been opened regarding the fail silently feature of exception handling in templates, both for and against. I sense that django leadership has yet to express an unequivocal opinion on the matter, which is unfortunate. I hope my observations will be appreciated here:
We all understand the need to facilitate debugging, but that shouldn't come at the expense of breaking production systems. On several occasions I have had users on my production site get server errors because of a backwards-incompatible change in the template fail silently feature between 1.2.7 and 1.3.1, of which I was not aware when I rolled out the update. It is almost impossible to identify now-broken templates a-priory and change them, so I expect more in the foreseeable future.
The rules for predicting when template rendering can raise an exception and when not should be IMO simple or at least intuitive and well documented. I have searched through the documentation and I have not found any reference to changes in the fail silently feature.
I personally would like to see fail silently reinstated completely for template rendering with DEBUG=TEMPLATE_DEBUG=False, for reasons stated above. If no explicit decision was made, than this is a functional bug. If the change was an intentional one, then this is a documentation bug; it should be documented very clearly.
I'm attaching the stand-alone test script which demonstrates the difference in behavior between the django versions. Below is the output from the script. Oddly, the DEBUG and TEMPLATE_DEBUG settings have very little effect.
Django version: 1.4 settings: {'DEBUG': False, 'TEMPLATE_DEBUG': False} ('{{ o.no_exception }}', u'Method') Caught exception: AttributeError() Django version: 1.4 settings: {'DEBUG': True, 'TEMPLATE_DEBUG': True} ('{{ o.no_exception }}', u'Method') Caught exception: AttributeError() Django version: 1.3 settings: {'DEBUG': False, 'TEMPLATE_DEBUG': False} ('{{ o.no_exception }}', u'Method') Caught exception: AttributeError() Django version: 1.3 settings: {'DEBUG': True, 'TEMPLATE_DEBUG': True} ('{{ o.no_exception }}', u'Method') Caught exception: TemplateSyntaxError(u'Caught AttributeError while rendering: ',) Django version: 1.2.7 settings: {'DEBUG': False, 'TEMPLATE_DEBUG': False} ('{{ o.no_exception }}', u'Method') ('{{ o.exception }}', u'') Django version: 1.2.7 settings: {'DEBUG': True, 'TEMPLATE_DEBUG': True} ('{{ o.no_exception }}', u'Method') ('{{ o.exception }}', u'')
Attachments (1)
Change History (4)
by , 13 years ago
Attachment: | template_err.py added |
---|
comment:1 by , 13 years ago
Cc: | added |
---|
comment:2 by , 13 years ago
Component: | Uncategorized → Template system |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
I'm not sure about the cause of the observed change from 1.2 to 1.3, and I can't find anything about it in the release notes or docs.
The change from 1.3 to 1.4 is, however, documented in the release notes. It did not change the situations in which an exception will be raised, it just changed which exception is raised when TEMPLATE_DEBUG = True
; I don't think there's any good justification for the previous exception-wrapping.
Personally, I'm +0 on reinstating thorough fail-silently with TEMPLATE_DEBUG = False
, but I can't claim to have kept up with all discussions on the topic over the past few years.
comment:3 by , 12 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
This ticket isn't really actionable. If you'd like to see something happen here, a thread on django-dev that clearly lays out what you're proposing is the right thing to do.
test script for template exception handling