Am 15.12.2009 um 19:57 schrieb Andrew Durdin: > On Dec 14, 11:00 pm, ab <andrewb...@gmail.com> wrote: >>> `wrap_and_raise()` will appear in the traceback, `raise >>> wrap_exception(SomeException())` would be cleaner. >> >> I like that > > But you must use the three-argument `raise` statement to supply your > own traceback in Python 2.x. You could dispense with the function > entirely if you're happy to repeat `import sys; raise NewException(), > None, sys.exc_info()[2]` instead--although then you lose some > information, see below.
I pictured the solution to be closer to PEP 3109 / Java: The wrapped exception as an attribute on the new exception, with the traceback attached in `exp.__cause__.__traceback__`. That's where my `WrappingException(.., wrap=True)` came from. I don't like the mangled tracebacks, but you're right - the reference cycle-free python 2.x solution probably is to use the tree-argument raise statement. >>> Your patch seems to swallow the new exception's traceback now >>> instead >>> of the causing traceback. That might be good in some situations, but >>> generally both should be preserved. > > No; the only part of the traceback lost is the `raise` line within > `wrap_and_raise`; the remainder of the traceback which would > correspond to all but the `raise` line of the new exception's > traceback is preserved. But if you weren't using the `wrap_and_raise` > function, you would lose the line of the traceback where the new > exception was raised. Put the following code in a python script and > compare the tracebacks when it calls wrapped(), unwrapped(), or > manually_wrapped(): My mistake, of course you're right. __ Johannes -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
