[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