Opened 13 years ago

Closed 9 years ago

Last modified 3 years ago

#6907 closed New feature (fixed)

Rethink the silent eating of exceptions in templates

Reported by: miohtama Owned by: nobody
Component: Template system Version: master
Severity: Normal Keywords: exception template silent failure
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Currently, it is impossible to attach a custom logger/stack trace printer which would print a traceable error message when a call from template files.

E.g. in the following template call:

<p>{% get_free_comment_count for webbridge.BlogAllEntry as comment_count %} comments</p>

We cannot know the reason causing get_free_comment_count fail - we have only empty string printed. The only way to debug this is to put some try...except and logging code to Django internals (comments.DoCommentCount in this case).

Django should provide a hook to 1) print exceptions fallen to templates as a normal debug page when DEBUG=True 2) provide a hook to catch these exceptions and log them in a custom way.

Have you been planning anything related to this?


Attachments (1)

template_error_silencing_configuration.patch (1.7 KB) - added by Gabriel Falcão 12 years ago.
Patch for explicit template fail in

Download all attachments as: .zip

Change History (10)

comment:1 Changed 12 years ago by Simon Greenhill

Triage Stage: UnreviewedAccepted

See discussion on django-developers

comment:2 Changed 12 years ago by Simon Greenhill

Summary: Silent eating of exceptions in templates considered harmfulRethink the silent eating of exceptions in templates

comment:3 Changed 12 years ago by Simon Greenhill

#7719 was a duplicate with patch.

Changed 12 years ago by Gabriel Falcão

Patch for explicit template fail in

comment:4 Changed 9 years ago by Julien Phalip

Resolution: fixed
Severity: Normal
Status: newclosed
Type: Uncategorized

Hmm, template processing does throw exceptions now (see the {% url %} tag for example). I presume something has changed in Django since 3 years ago making this ticket redundant.

comment:5 Changed 9 years ago by Julien Phalip

Resolution: fixed
Status: closedreopened
Type: UncategorizedNew feature

Sorry, I might have closed this a bit too quickly. See #11421 for a related issue.

comment:6 Changed 9 years ago by Aymeric Augustin

Easy pickings: unset
Resolution: fixed
Status: reopenedclosed
UI/UX: unset

I believe this is fixed in trunk. Variable._resolve_lookup goes to great lengths not to catch inadvertently exceptions raised in user code. Please re-open this ticket if you still encounter situations where this issue exists.

comment:7 Changed 8 years ago by anonymous

There is still an issue here when a TypeError is raised by the function that is called. This is marked as a GOTCHA in Variables._resolve_lookup, but I think it might be a common case. People new to Django will often encounter TypeErrors when trying to iterate over a Manager object rather than using the all() method.

comment:8 Changed 3 years ago by Christian González

Sorry for resurrecting this ticket - I found no other open one. Does this ticket also apply to variables that are not found (because e.g. misspelled)?
When I write

{{ nonexisting_variable }}

in a template; nothing happens, Django happily renders the page without telling me that there is a wrong variable in a template.


  {% for counter in existing_variable %}
      <div>{{ counters }}</div>
  {% endfor %}

shows nothing, no error and no output (mind the wrong 's' after counter) - so variables declared IN the template are not checked neither.

Is there a chance that this is getting improved?

Last edited 3 years ago by Christian González (previous) (diff)

comment:9 Changed 3 years ago by Tim Graham

Nonexistent template variables passing silently is a documented feature.

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