Django hiding exceptions

[richard@…]

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).

[Russell Keith-Magee]

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?

[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.

[Russell Keith-Magee]

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.

[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.

[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.

[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(), {}, {})

[Adrian Holovaty]

I believe this has been fixed.