Rethink the silent eating of exceptions in templates

[miohtama]

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 event.blog_all_entry.id 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?

'

[Simon Greenhill]

See discussion on ​django-developers

[Simon Greenhill]

#7719 was a duplicate with patch.

[Gabriel Falcão]

Patch for explicit template fail in settings.py

[Julien Phalip]

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.

[Julien Phalip]

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

[Aymeric Augustin]

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.

[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.

[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.

Also,

  {% 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?

[Tim Graham]

Nonexistent template variables passing silently is ​a documented feature.