[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