[Twisted-Python] If the errbacks of a canceled Deferred are called with error other than CancelledError, is this acceptable?
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Thu Jun 20 13:34:35 MDT 2013
On 19 Jun, 07:49 pm, tom.prince at ualberta.net wrote:
>
>Well, it already raises `CancelledError`. Every deferred that doesn't
>have explicitly handle cancelling already does:
>
>from twisted.mail import smtp
>from twisted.python import log
>
>d = smtp.sendmail("host", "options.sender", [], "")
>d.cancel()
>d.addErrback(log.err, "Here be CancelledError")
Thank you for pointing this out. It seems like an important fact that
makes the rest of the discussion moot.
By making `Deferred.cancel` work on any Deferred by triggering a
`CancelledError`, we have already decided on the failure behavior for
all existing Deferred-returning APIs. Changing that at this point
doesn't seem like a very good idea.
I think I'd also like to challenge the idea that Glyph put forwards
earlier in the thread that this extra information is *necessarily*
important to the application.
So far, I haven't written any applications that care about the exact
stage at which the operation is cancelled. All they care about is that
the operation *is* cancelled (ie, resources are cleaned up) and that the
Deferred fires soon. There's lots of utility in just this level of
functionality which requires no extra information about the internal
progress of the operation.
This is not to say that I believe there is no application that might
want this information, but maybe someone can propose some concrete use
cases for this information and design can follow from that. So far I
don't think any practical justification to do anything other than
`CancelledError` has been presented.
Jean-Paul
More information about the Twisted-Python
mailing list