[Twisted-Python] failure.Failure

Christopher Armstrong carmstro at twistedmatrix.com
Mon May 6 22:11:23 EDT 2002


On Sun, 2002-05-05 at 20:21, Glyph Lefkowitz wrote:
> On Sat, 2002-05-04 at 02:20, Christopher Armstrong wrote:
> >   The issue now is what the trap() API should be like. It used to be
> > that fail.trap(types, that, I, want, to, trap) would re-raise the
> > Failure if any of the types matched. This was kinda weird, as it
> > requires code like:
> 
> You've got that backwards.  It would re-raise the exception if _none_ of
> the types matched.
> 
> I consider this behavior important, since unless you raise an exception
> or return a Failure, the next deferred stack call will be a callback,
> not an errback.

Just realized - what if I want to handle two or more different failure
types differently in the same errback?

==
def _ebFoo(self, failure):
    try:
        failure.trap(Foo)
        print "it's a foo!"
    except failure.__class__: #???
        pass

    try:
        failure.trap(Bar)
        print "it's a bar!"
    except failure.__class__:
        pass

    failure.trap(Baz)
    print "it's a baz!"
==

I hope I'm missing something obvious here, because this is *freaking
ugly*. :-)

-- 
                                Chris Armstrong
                         << radix at twistedmatrix.com >>
                http://twistedmatrix.com/users/carmstro.twistd/





More information about the Twisted-Python mailing list