On 05:16 pm, chris@simplistix.co.uk wrote:
On 29/09/2010 17:16, Phil Mayers wrote:
No.
The problem is that your example is malformed.
Well, it's not, it's the reality of the situation and one I'd like to protect against; "the scheduler must not die" is the rule I need to make work...
You do this:
1. Create a deferred on the "Break" class instance
The "Break" class, in reality, is the bowels of twisted.protocols.ftp.FTPClient, copying from my previous mail:
self.failIfNotConnected(error.getConnectError((err, strerror(err)))) File "Twisted-8.2.0-py2.5-linux-x86_64.egg/twisted/internet/tcp.py", line 588, in failIfNotConnected del self.connector --- <exception caught here> --- File "ourcode.py", line 180, in checkSchedule yield self.sendTransmissions(...) exceptions.GeneratorExit:
How can I protect my scheduler against code which doesn't catch an exception when it should?
Then you're talking about an API in Twisted which returns a Deferred that sometimes doesn't errback when the implementation encounters an error. Also, `failIfNotConnected` should never raise an exception. These sound like bugs. File a couple tickets. With a unit tests please. :) Jean-Paul