[Twisted-Python] If the errbacks of a canceled Deferred are called with error other than CancelledError, is this acceptable?

[Tom Prince]

Glyph <glyph at twistedmatrix.com> writes:

> On Jun 18, 2013, at 8:42 AM, Christopher Armstrong <radix at twistedmatrix.com> wrote:
>
>> On Tue, Jun 18, 2013 at 8:37 AM, Itamar Turner-Trauring <itamar at futurefoundries.com> wrote:
>> I believe the specific module he is working on is the POP3 client,
>> but it's a general question - should we try to keep CancelledError
>> percolating all the way to the top of callback chain when possible?
>> My first thought is "yes" since that's a more informative reason, but
>> maybe someone else has a counter-argument
>> 
>> I definitely think the error should explain that cancellation
>> occurred; I can also imagine cases where you'd want to know the
>> specifics of how that cancellation occurred, or how far some
>> operation got before the cancellation was executed (especially if
>> we're talking about mutating operations). ConnectionDone definitely
>> doesn't sound good.
>
> Making an API that previously documented raising (or failing)
> exception types A, B, and C raise (or fail with) D is not necessarily
> a compatible change.  Making it raise (or fail with) A' (a subclass of
> A) is, though.

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")