On 30/09/2010 00:31, Glyph Lefkowitz wrote:
There are so many ways.
Yes, that's what I thought, which is why I was confused to keep on getting "fix the code" responses when I'd already pointed out it wasn't my code to fix, and I'd like to build a solution that caters even for this eventually...
You can add a log observer that handles isError=True log messages.
Okay, and this would mean that my `loop` function from the example I posted would keep getting called by LoopingCall?
You can write a 'safetyBelt' function that catches the exception and does something with it.
From my original example, I'm pretty sure that's what my `loop` function is; I'm confused as to why it catches a GeneratorExit when the attribute error is indirectly raised in the `doStuff` function, and more confused that even thought the GeneratorExit has been caught, the calls to `loop` from LoopingCall cease...
You can always invoke your code with maybeDeferred, which will turn exceptions into failures for you.
In "the real app", we have another layer or two between doStuff and Break, one of which does call down with maybeDeferred, doesn't make any difference...
You can use inlineCallbacks, where in 'x = yield y()', y() raising an exception and y() returning a failed Deferred are basically indistinguishable to the caller.
Yes, as you can see, this is what `loop` does. In "the real app", doStuff is actually @inlineCallbacks as well, the level below that calls with a maybeDeferred and so yes, doing this, same result...
Why would you say there's no way?
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 ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk