Opened 16 years ago
Closed 15 years ago
#11368 closed (duplicate)
debug error reporter should include traceback for nested exceptions
Reported by: | John Firebaugh | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | 1.0 |
Severity: | Keywords: | ||
Cc: | glenn@… | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
There are a number of place in the django codebase that trap Exception and then raise a new exception. This results in less-than-ideal debugging information being presented in the default error page; in particular, the traceback from the original exception is unavailable.
Most recently, I encountered this in the template renderer:
class DebugNodeList(NodeList): def render_node(self, node, context): try: result = node.render(context) except TemplateSyntaxError, e: if not hasattr(e, 'source'): e.source = node.source raise except Exception, e: from sys import exc_info wrapped = TemplateSyntaxError(u'Caught an exception while rendering: %s' % force_unicode(e, errors='replace')) wrapped.source = node.source wrapped.exc_info = exc_info() raise wrapped return result
When this wrapped TemplateSyntaxError is displayed in the default error page, the traceback ends at the 'raise wrapped' line; the only part of the original exception that is available is the message ("'RelatedManager' object is not iterable" in my current case). This makes the source of the problem more difficult to determine. The traceback in wrapped.exc_info should be displayed in addition to, or instead of, the traceback currently displayed.
This was briefly discussed (exactly 1 year ago) on django-developers. A partial patch was posted.
Change History (4)
comment:1 by , 15 years ago
Cc: | added |
---|
comment:3 by , 15 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
comment:4 by , 15 years ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
(actually, this is more of a duplicate than a wontfix)
This isn't the right fix. This would have to be implemented in every custom exception reporter, including third-party ones that don't know about Django exceptions at all.
The actual problem is that DebugNodeList is raising the new exception incorrectly. It needs to include the original traceback.
See #11461.