On Thu, 17 Feb 2005 01:05:22 +0000, Phil Mayers
On Wed, Feb 16, 2005 at 04:28:32AM +0000, Jp Calderone wrote:
On Tue, 15 Feb 2005 19:56:15 -0800, Dave Cook
wrote: I'm rendering the results of a remote method call:
def data_tableList(self, ctx, data): ... d = self.pbClientFactory.login(creds) d.addCallback(lambda object: object.callRemote("foo")) return d
Always always always use errbacks. *Especially* for Deferreds that can fail due to transient network conditions.
See, that depends. I ran into this just today in fact, and found that if the server has gone away, then you'll get an exception *right then*, not via the errback:
def do_stop(self): try: self.root.callRemote('stop', self).addCallbacks(self.stop, self.err) except pb.DeadReferenceError, re: self.stale()
Why, why, why why why doesn't the DeadReferenceError go down the errback? As it is, the code has to be littered with both synchronous and asynchronous error handling, which is needlessly irritating, surely?
Yes, this is unfortunate. Changing it will break programs that handle the error as it currently occurs, though. Brian Warner has been working on an improved version of PB for some time. It is mostly API compatible, and does a lot fewer irritating things of this sort.
The original poster may find his problem was a DeadReferenceError that's getting silently eaten (or just not GCed right away) by the framework, as I did.
Not quite. Twisted doesn't silently eat failures. But if you forget to add an errback, it might seem that way :) So this should just be taken as emphasis on my original point. If there _are_ framework pieces that are supposed to become responsible for a Deferred's error handling but aren't setting up errbacks, that's a bug. If you know of any, please report them on the bug tracker. (The Nevow example James Knight pointed out is probably one such case.) Jp