Opened 13 years ago

Closed 12 years ago

#18155 closed Bug (invalid)

Undocumented changes, indecision, in template fail silently exception handling

Reported by: Aryeh Leib Taurog <vim@…> 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)

template_err.py (739 bytes ) - added by Aryeh Leib Taurog <vim@…> 13 years ago.
test script for template exception handling

Download all attachments as: .zip

Change History (4)

by Aryeh Leib Taurog <vim@…>, 13 years ago

Attachment: template_err.py added

test script for template exception handling

comment:1 by Aryeh Leib Taurog <vim@…>, 13 years ago

Cc: vim@… added

comment:2 by Carl Meyer, 13 years ago

Component: UncategorizedTemplate system
Triage Stage: UnreviewedDesign 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 Jacob, 12 years ago

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top