On 01/10/10 14:19, Chris Withers wrote:
On 30/09/2010 18:01, Phil Mayers wrote:
It is more than a little confusing, and I'm sure frustrating.
I've tried to produce something like this locally, but cannot.
The very first message in this thread (28th Sept, 14:48) and my email of 30th Sept, 14:36 both had scripts attached which do exactly this..
If your examples scripts genuinely reflect the problem (a bit of code, outside your control, is raising an exception in a context where the error doesn't flow back to user code) then Glyph is (of course!) right - you're not going to be able to capture and log the error "nicely". It will be propagated upwards until it hits the reactor.
You want this loop function to catch& log all exceptions resulting from work it initiates.
Yep, errbacks, internal twisted bugs, whatever. As long as they're logged by something, preferabyl the try-except above, I don't mind. What absolutely must not cannot ever happen is for the scheduler to die ;-)
Now *this* you should be able to do. A LoopingCall will only die (i.e. stop permanently) if you: 1. Raise an exception 2. Return a deferred which errback's (The former gets turned into the latter) If you ensure your loop never ever does this, it'll run forever. HOWEVER: as JP has mentioned, a LoopingCall *will* pause if you return a deferred, until that deferred callback's (or errback's, then it dies) So this: def loop(): try: somework() except: pass ...should never ever die (because it can't raise an exception) or stop (because it doesn't return a deferred)