Opened 8 years ago

Closed 4 years ago

Last modified 4 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 GabrielFalcao 7 years ago.
Patch for explicit template fail in

Download all attachments as: .zip

Change History (8)

comment:1 Changed 7 years ago by Simon Greenhill

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

See discussion on django-developers

comment:2 Changed 7 years ago by Simon Greenhill

  • Summary changed from Silent eating of exceptions in templates considered harmful to Rethink the silent eating of exceptions in templates

comment:3 Changed 7 years ago by Simon Greenhill

#7719 was a duplicate with patch.

Changed 7 years ago by GabrielFalcao

Patch for explicit template fail in

comment:4 Changed 5 years ago by julien

  • Resolution set to fixed
  • Severity set to Normal
  • Status changed from new to closed
  • Type set to 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 5 years ago by julien

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Type changed from Uncategorized to New feature

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

comment:6 Changed 4 years ago by aaugustin

  • Easy pickings unset
  • Resolution set to fixed
  • Status changed from reopened to closed
  • 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 4 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.

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