Glyph <[email protected]> writes:
> On Jun 18, 2013, at 8:42 AM, Christopher Armstrong <[email protected]>
> wrote:
>
>> On Tue, Jun 18, 2013 at 8:37 AM, Itamar Turner-Trauring
>> <[email protected]> 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")
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
