Code

Opened 2 years ago

Closed 13 months 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@…> 2 years ago.
test script for template exception handling

Download all attachments as: .zip

Change History (4)

Changed 2 years ago by Aryeh Leib Taurog <vim@…>

test script for template exception handling

comment:1 Changed 2 years ago by Aryeh Leib Taurog <vim@…>

  • Cc vim@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 2 years ago by carljm

  • Component changed from Uncategorized to Template system
  • Triage Stage changed from Unreviewed to 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 Changed 13 months ago by jacob

  • Resolution set to invalid
  • Status changed from new to 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.