[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