[Twisted-Python] understanding deferreds

twisted-web at udmvt.ru twisted-web at udmvt.ru
Fri Jan 29 05:17:22 EST 2010

On Thu, Jan 28, 2010 at 05:46:08PM -0500, Terry Jones wrote:
> >>>>> "Michael" == Michael P Soulier <msoulier at digitaltorque.ca> writes:
> Michael> I'm a bit confused as to the "visual explanation". It seems like
> Michael> if you have a single callback and errback, that if the errback
> Michael> wants to swallow the error, the callback will not be called at
> Michael> all, since deferred processing will look for the second callback
> Michael> at that point by the diagram.
> Michael> So, right now I'm calling my own callback from the errback if I
> Michael> want to swallow the error. Is there a better way?
> Yes. Add the errback to the deferred and then add the callback.
>   d = somethingReturningADeferred()
>   d.addErrback(cleanup)
>   d.addCallback(dealWithResult)
> If cleanup doesn't return the failure object it's passed or raise some an
> exception, processing will pass to dealWithResult. Note that dealWithResult
> will get as an argument whatever cleanup returns (that means None if cleanup
> doesn't explicitly return something).
> You're thinking about this in the right way. Understanding the difference
> between the above and 
>   d = somethingReturningADeferred()
>   d.addCallbacks(dealWithResult, cleanup)
> is important.

Is it true, that adding many callback functions as filters is elegant,
but impractical solution?
Since there is only a [linear] list of pairs (callback, errback), the last errbacks
have to be complex to distinguish the failures, that came from the previous callback
from failures, that traverse the errback chain from the beginning.

Should I only use errbacks as a means of catching errors only from who have produced the Deferred?
And never use them to catch errors, that came from my callbacks?

Nevertheless the Deferred mechanism always catch the exceptions in my callbacks,
I have to always catch them myself and never let them out uncontrolled (since I cannot
distinguish, say TypeError that came from the first callback from TypeError, that came
from the next callback, and they are not the same for me, since I try to do a cleanup)?
But then I have to translate all errors to my invented exceptions, so they will differ.

Or may I pause() a Deferred in a errback, after I have processed the error and want no
error propagation any further?
If I can pause(), what can I do if my code is not the final consumer of the Deferred's
result, but lives in the middle of the processing chain and have to pass the signal, that there
will be no further result, so the consumer will do appropriately?

Maybe we need graph of callbacks (or just tree)? 
Or, said in other words, groups of callbacks (to be able to exit the processing
of the current group on some failures)?

Or just tell me, that I have missed something, I'm still getting into the theme!


> Terry
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Alexey S

More information about the Twisted-Python mailing list