[Twisted-Python] Deferred execution, timeouts, and unhandled exceptions

Andrew Bennetts andrew-twisted at puzzling.org
Sat Jan 18 07:57:53 EST 2003

On Sat, Jan 18, 2003 at 11:26:38PM +1100, Andrew Bennetts wrote:
> On Fri, Jan 17, 2003 at 07:04:01PM -0500, Bob Ippolito wrote:
> > I've noticed that there isn't really a good/standard way to do timeouts 
> > (without bad things happening) or cancel deferreds in Twisted [without 
> > subclassing everything you use, which isn't good in my book].
> I've glanced at your code and log, but it's not immediately clear to me what
> the problem is...

Nevermind me, I shouldn't try to read code and post when I'm tired.

Your problem (if I'm understanding correctly :), is that exceptions are
raised by calling Deferred.callback, if that Deferred has timed out, or
otherwise been "cancelled" (by having its errback called).

I'm tempted to argue that this is a feature: the code attempting to fire the
callback probably should know that the Deferred has already expired due to
an error.  The obvious problem with this is that alot of the time you don't
care if the Deferred has already fired or not, and wrapping d.callback(x) in
a try/except AlreadyCalledError is hardly convenient.

So I'd still like at least the option for an exception to be raised, even if
it's disabled by default.  I can't shake the feeling that some apps will
need to know that it succeeds... although I guess they could just register
their own .errback if they really care?

For that matter, perhaps another solution would be to mandate that a method
creating a Deferred is responsible for configuring it with an errback that
will cancel pending operations so that .callback won't be called.  Ugh,
that's a confusing sentence.  What I'm trying to say is that similarly to
how when FTP opens a port and waits for a connection, it must set an errback
to close that port if the connection never comes (e.g. due to an error on
the control connection), whatever "owns" the Deferred should also cancel
whatever would call .callback if an error occured -- this is probably
necessary in general, not just for timeouts and cancels.

Interesting problem :)


More information about the Twisted-Python mailing list