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

Glyph glyph at twistedmatrix.com
Tue Jun 18 12:22:43 MDT 2013


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:
> By way of background, Kai Zhang is one of our GSoC interns, working on adding Deferred cancellation support to Twisted. 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.

I would say that if we want to percolate this information up to the caller, there should be a ConnectingCancelled exception that is a subtype of the previous exception type.

After all, if it's interesting that the operation was cancelled, presumably it's interesting at what stage the operation is cancelled.

For precedent, IStreamClientEndpoint went with this strategy by having the (perhaps unfortunately named) UserError.

-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-python/attachments/20130618/56c9492c/attachment.html>


More information about the Twisted-Python mailing list