[Twisted-Python] failure.Failure

Christopher Armstrong carmstro at twistedmatrix.com
Sun May 5 23:59:31 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.

Aha! I didn't know about that :-) This makes things much more
interesting, hrm... So, an errback that wants to handle some particular
exception need only do:

def _ebFoo(self, failure):
    failure.trap(stuff, I, care, about)
    doStuff()

Check this out from forum/gadgets.py:

    def _errIdentity(self, failure):
        if failure.trap(self.manager.dbpool.dbapi.OperationalError):
            return self.tryAgain("This identity is already taken.",
                                 self.request)

What's up with that? Oh well, I'll just assume that whoever wrote this
code didn't understand the way failure.trap() works -- I will keep the
.trap() api as you suggested above.


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





More information about the Twisted-Python mailing list