[Twisted-Python] how to write a safe catch-all
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
> 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
More information about the Twisted-Python