<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 18, 2013, at 8:42 AM, Christopher Armstrong <<a href="mailto:radix@twistedmatrix.com">radix@twistedmatrix.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr">On Tue, Jun 18, 2013 at 8:37 AM, Itamar Turner-Trauring<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:itamar@futurefoundries.com" target="_blank">itamar@futurefoundries.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div dir="ltr">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</div></blockquote><div><br></div><div>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.</div></div></div></div></div></blockquote><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">After all, if it's interesting that the operation was cancelled, presumably it's interesting <i>at what stage</i> the operation is cancelled.</div><div dir="auto"><br></div><div dir="auto">For precedent, IStreamClientEndpoint went with this strategy by having the (perhaps unfortunately named) UserError.</div><div dir="auto"><br></div><div dir="auto">-glyph</div></body></html>