Opened 17 years ago

Closed 13 years ago

Last modified 7 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: dev
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

Description

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?

'

Attachments (1)

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

Download all attachments as: .zip

Change History (10)

comment:1 by Simon Greenhill, 16 years ago

Triage Stage: UnreviewedAccepted

See discussion on django-developers

comment:2 by Simon Greenhill, 16 years ago

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

comment:3 by Simon Greenhill, 16 years ago

#7719 was a duplicate with patch.

by Gabriel Falcão, 16 years ago

Patch for explicit template fail in settings.py

comment:4 by Julien Phalip, 14 years ago

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 by Julien Phalip, 14 years ago

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 by Aymeric Augustin, 13 years ago

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 by anonymous, 12 years ago

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 by Christian González, 7 years ago

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?

Version 0, edited 7 years ago by Christian González (next)

comment:9 by Tim Graham, 7 years ago

Nonexistent template variables passing silently is a documented feature.

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