Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#1236 closed defect (fixed)

Django hiding exceptions

Reported by: richard@… Owned by: Russell Keith-Magee
Component: Template system Version: 0.90
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


I just got an exception "TemplateSyntaxError: Caught an exception while rendering." Looking into the code where that exception was being raised, I see that it's actually squashing another exception (anything with subclass Exception) and re-raising the useless message I got.

I eventually narrowed down the code that was raising the initial exception, and put my own try/except block around it, and found that the exception really being raised is at result of passing an invalid value to an object constuctor (a meta.Model object, this is). Clearly *not* a template syntax error.

Please don't squash exceptions.

The offending (offensive?) code is the "wrapped" section of DebugNodeList in django/core/template/ (currently terminating on line 742).

Change History (7)

comment:1 Changed 12 years ago by Russell Keith-Magee

Owner: changed from Adrian Holovaty to Russell Keith-Magee
Status: newassigned

The exception isn't completely squashed; the TemplateSyntaxError has an exc_info attribute that contains a tuple storing the exception, any extra data passed with the exception, and the stack frame at the time of the original exception.

However, I can see your point, especially if the wrapped error isn't getting rendered clearly to the end user.

Can you provide an example of what you were doing (and more importantly, where you were doing it) to throw an exception? Specifically, was it view code, a template filter, model code or something else?

Also, what version of Django are you working with?

comment:2 Changed 12 years ago by richard@…

Was working with the current release version, 0.91

The error that caused the exception was an incorrectly-formed model creation statement. I was trying to add a new poll response to the database, but was passing the wrong values. Instead of:

r = responses.Response(option=option, value=value,

user=request.user, poll=poll)

I was passing:

r = responses.Response(option=option_id, value=value,

user=request.user, poll=poll_id)

causing the exception. Sorry, I don't have the exact code any more.

comment:3 Changed 12 years ago by Russell Keith-Magee

Version: 0.9

I'm still unclear as to where you were getting this exception. Where were you (attempting to) add the poll response?

Was it in a view method? Or at a python prompt while you messed around with the model? Or somewhere else? This is significant because it will affect the layers of wrapping that are around your error.

comment:4 Changed 11 years ago by rhettg@…

Has anybody figured out fix or workaround for this problem?
It looks to me like the default debug.technical_500_response(request, *sys.exc_info()) is actually generating an exception when it tries to generate the 500 response page. So all I get is the exception handler provided by basehttp instead of some handler that might be smart enough to decode a template error.

Any ideas? I've hit this a couple of times now, it sure would be easier to debug with a proper trace.

comment:5 Changed 11 years ago by Russell Keith-Magee

Can you provide an example demonstrating the problem? The ticket has become stale because the original submitter couldn't/didn't provide an example of the problem, or explain exactly what exception was getting swallowed, and where.

comment:6 Changed 11 years ago by anonymous

One occasion where I get this exception is using a model in, that has not been imported.

# comments is not imported
comment = formfields.FormWrapper(comments.AddManipulator(), {}, {})

comment:7 Changed 11 years ago by Adrian Holovaty

Resolution: fixed
Status: assignedclosed

I believe this has been fixed.

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