[Twisted-Python] Making a duck-typed traceback from a Failure
![](https://secure.gravatar.com/avatar/1327ce755b24b956995d68accae3eab2.jpg?s=120&d=mm&r=g)
Hello, I've recently been doing work with Twisted tests from within the Zope testrunner. It's a real pain because if the tests or their callbacks raise exceptions, no traceback gets given to the result object. See #2495. The fix I've uploaded doesn't actually help me. By the time the result object gets the failures, they've been cleaned with cleanFailure -- Failure.tb is None and everything is a string. Is it possible to make a duck-typed traceback from a cleaned Failure? I haven't really looked into it, but I can't think of why not off the top of my head. Granted I ran out of thought gluons a couple of hours ago. cheers, jml
![](https://secure.gravatar.com/avatar/1327ce755b24b956995d68accae3eab2.jpg?s=120&d=mm&r=g)
On 2/28/07, Jonathan Lange <jml@mumak.net> wrote:
<exarkun> jml: if you refine the question with some details (why isn't there a real traceback, what do you want to do with the reconstructed traceback, etc), I might be able to produce some useful feedback 1. Why isn't there a real traceback The failure is caught in an errback in Trial's run(). Deferred._runCallbacks calls Failure.cleanFailure on any failures that are returned from Deferreds. By the time the TestResult object gets the failure, cleanFailure() has been run on it. cleanFailure() sets Failure.tb to None, and converts all of the frames into strings. This ensures that we don't keep references to a billion different objects every time there is a failure. 2. What do I want to do with it I want to pass the duck-typed traceback along with the exception type and exception value to traceback.format_exception. cheers, jml
![](https://secure.gravatar.com/avatar/7ed9784cbb1ba1ef75454034b3a8e6a1.jpg?s=120&d=mm&r=g)
On Thu, 1 Mar 2007 11:16:17 +1100, Jonathan Lange <jml@mumak.net> wrote:
To clarify slightly (this may be what you meant), _runCallbacks only calls cleanFailure on Failures which run into the end of the callback chain. So any Failure which is returned by a callback while there is an errback left to be processed will not have cleanFailure called on it.
Is it particularly important that the exception be formatted using that particular function? Failure.printTraceback() exists to deal with the fact that Failure doesn't play nicely with the traceback module. If you absolutely must go through format_exception, then I guess you can create an object which is traceback-like enough for the traceback module. It probably wouldn't even be /that/ tedious. I don't have any particular suggestions for doing this. Traceback objects have some attributes, I think you'll just need to make a class and give it some attributes (and another for frames). Jean-Paul
![](https://secure.gravatar.com/avatar/1327ce755b24b956995d68accae3eab2.jpg?s=120&d=mm&r=g)
On 3/1/07, Jean-Paul Calderone <exarkun@divmod.com> wrote:
It is important. unittest in the standard library and the Zope testrunner both use format_exception to display errors.
I'll do this then. Thanks, jml
![](https://secure.gravatar.com/avatar/1327ce755b24b956995d68accae3eab2.jpg?s=120&d=mm&r=g)
On 2/28/07, Jonathan Lange <jml@mumak.net> wrote:
<exarkun> jml: if you refine the question with some details (why isn't there a real traceback, what do you want to do with the reconstructed traceback, etc), I might be able to produce some useful feedback 1. Why isn't there a real traceback The failure is caught in an errback in Trial's run(). Deferred._runCallbacks calls Failure.cleanFailure on any failures that are returned from Deferreds. By the time the TestResult object gets the failure, cleanFailure() has been run on it. cleanFailure() sets Failure.tb to None, and converts all of the frames into strings. This ensures that we don't keep references to a billion different objects every time there is a failure. 2. What do I want to do with it I want to pass the duck-typed traceback along with the exception type and exception value to traceback.format_exception. cheers, jml
![](https://secure.gravatar.com/avatar/7ed9784cbb1ba1ef75454034b3a8e6a1.jpg?s=120&d=mm&r=g)
On Thu, 1 Mar 2007 11:16:17 +1100, Jonathan Lange <jml@mumak.net> wrote:
To clarify slightly (this may be what you meant), _runCallbacks only calls cleanFailure on Failures which run into the end of the callback chain. So any Failure which is returned by a callback while there is an errback left to be processed will not have cleanFailure called on it.
Is it particularly important that the exception be formatted using that particular function? Failure.printTraceback() exists to deal with the fact that Failure doesn't play nicely with the traceback module. If you absolutely must go through format_exception, then I guess you can create an object which is traceback-like enough for the traceback module. It probably wouldn't even be /that/ tedious. I don't have any particular suggestions for doing this. Traceback objects have some attributes, I think you'll just need to make a class and give it some attributes (and another for frames). Jean-Paul
![](https://secure.gravatar.com/avatar/1327ce755b24b956995d68accae3eab2.jpg?s=120&d=mm&r=g)
On 3/1/07, Jean-Paul Calderone <exarkun@divmod.com> wrote:
It is important. unittest in the standard library and the Zope testrunner both use format_exception to display errors.
I'll do this then. Thanks, jml
participants (2)
-
Jean-Paul Calderone
-
Jonathan Lange