including the nested exception's traceback in new raised exception

[Graham Carlyle]

Hi

There are a number of place in the django codebase that trap Exception
and then raise a new exception but only convert the original exception
to a string to indicate what went wrong. Its often necessary to see the
full traceback of the original exception to work out whats going wrong.
The one that traps exceptions from urlconf in django.core.urlresolvers
seems to bite me most often as I often use a references to functions in
my url conf.

I haven't been able to find discussion of this in the mailing list or a
trac ticket but might have missed it :) which surprises me as now and
then I've had to patch django to find out whats really going wrong with
my code.

I guess the simplest solution would be a helper function that formats
the traceback for use in the newly raised exceptions message string.

Along the lines of...

import sys
import traceback

def formatted_traceback():
return '\n'.join(traceback.format_exception(*sys.exc_info()))
...

except Exception, e:
raise ImproperlyConfigured, "Foo: %s\nNested traceback: %s" % (e,
formatted_traceback())

cheers,
Graham

[Thomas Guettler]

Graham Carlyle schrieb:

> Hi
>
> There are a number of place in the django codebase that trap Exception
> and then raise a new exception but only convert the original exception
> to a string to indicate what went wrong. Its often necessary to see the
> full traceback of the original exception to work out whats going wrong.
> The one that traps exceptions from urlconf in django.core.urlresolvers
> seems to bite me most often as I often use a references to functions in
> my url conf.
>
>

Yes, sometimes it is hard to find the root of the problem, if the
original exception got trapped. This needs improvement.

I created some tickets:

Special case for transaction decorator:
http://code.djangoproject.com/ticket/6623

Generic solution:
http://code.djangoproject.com/attachment/ticket/6537/6537.diff

If an exception has an attribute original_exc_info, it will be displayed
in the debug view.

But a better solution would be to have a stack of original exceptions, since
a exception might be cought several times in django.

Thomas

--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de