[Twisted-Python] how to write a safe catch-all

Chris Withers chris at simplistix.co.uk
Wed Sep 29 20:52:12 EDT 2010

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 

> 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 ;-)


Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

More information about the Twisted-Python mailing list