Code

Opened 6 years ago

Closed 3 years ago

Last modified 2 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

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 GabrielFalcao 6 years ago.
Patch for explicit template fail in settings.py

Download all attachments as: .zip

Change History (8)

comment:1 Changed 6 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 6 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 6 years ago by Simon Greenhill

#7719 was a duplicate with patch.

Changed 6 years ago by GabrielFalcao

Patch for explicit template fail in settings.py

comment:4 Changed 3 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 3 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 3 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 2 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.

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.