Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#1236 closed defect (fixed)

Django hiding exceptions

Reported by: richard@… Owned by: russellm
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:

Description

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/init.py (currently terminating on line 742).

Change History (7)

comment:1 Changed 9 years ago by russellm

  • Owner changed from adrian to russellm
  • Status changed from new to assigned

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 9 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 9 years ago by russellm

  • Version set to 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 9 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 9 years ago by russellm

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

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

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

comment:7 Changed 9 years ago by adrian

  • Resolution set to fixed
  • Status changed from assigned to closed

I believe this has been fixed.

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