[Twisted-Python] understanding deferreds

[Andrew Bennetts]

Landreville wrote:
> On Sat, Jan 30, 2010 at 2:16 AM, Andrew Bennetts <andrew at bemusement.org> wrote:
> > twisted-web at udmvt.ru wrote:
> > [...]
> >> 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.
> >
> > This is no different to regular Python code, which has a linear call stack which
> > can have exception handlers at any point on the stack.  The exact same tradeoffs
> > apply about which exceptions to raise and which to catch, and at what points.
> >
> > -Andrew.
> >
> 
> In normal python code you might put each filter into a try/except
> block, wouldn't this be equivalent to putting a callback and errback
> (addCallbacks) each time you are adding a callback. So that the
> errback would then know which callback (the previous one) failed.

Yes and no.

Yes, you could use addCallbacks as you suggest to get a clearer idea of
where an exception was raised from, and that approach certainly suits
some code.

But unless your Python code usually uses bare excepts (“except:” rather
than “except SpecifcException:”), which is generally bad style, you
can't be sure without horrible introspection where precisely in the code
the exception was raised from.  But then, you generally don't need to
know... e.g. it rarely matters where a KeyboardInterrupt happened, you
probably will always want to respond to it the same way.

Again, to mind at least, the tradeoffs of bare excepts vs. specific
exception handlers have very direct parallels with Deferred
callback/errback chains.  Ditto for how much code should be inside a
“try” block, etc.  They are just exception handlers for async code, the
way you should deal with exceptions might be spelled rather differently
but the principles are the same.

-Andrew.