On Jun 18, 2013, at 8:42 AM, Christopher Armstrong <ra...@twistedmatrix.com>
wrote:
> On Tue, Jun 18, 2013 at 8:37 AM, Itamar Turner-Trauring
> <ita...@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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
