On 30/09/2010 04:45, exar...@twistedmatrix.com wrote: > On 12:52 am, ch...@simplistix.co.uk wrote: >> >> Because I haven't found any permutation that doesn't result in the >> LoopingCall's calls to `loop` from stopping after the exception. >> >> I would be more than ecstatic to be proved wrong ;-) > > You keep saying the LoopingCall stops. It does not stop. It is waiting > for a result.
What result is it waiting for and how do I pass that from the `loop` function in my first example when the exception is caught? > If you provide it with a result, it will proceed. See above: how do I do that? > Glyph > suggested a number of (hackfully) mechanisms you might use to provide it > with a result. Why do you say hackfully? I'm trying to build a scheduler that is resilient to failure in a scheduled task. Yes, of course I want to fix that failure, but I don't want a failure in one scheduled task to prevent any further scheduled tasks from being executed... > I suggested another way (fix the broken code, or at > least supply enough information for someone else to fix it). For all I know, it's already fixed in a newer version of Twisted (unfortunately, I can't move this project to a newer version of Twisted) but once I have a robust scheduler, I'll certainly do my best to report the underlying failure to you guys properly... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python