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

[Terry Jones]

Hi JP

Thanks for the summary. I agree (and agreed in my first post in this
thread) that the CancelledError should (has to) come all the way back. I
missed that we were still talking about that.

Was there a conclusion on Glyph's suggestion of using subclasses of
CancelledError? Chris raised the point that there might be many of them for
a given API. But an API could define a few subclasses, just the most useful
to start with (if there are any at all), and document them, and later
define some more if need be, etc. That would be backwards consistent with
processing by Failure.check and try/except on CancelledError - unless my
Python memory has rotted more than I think. It seems a good path to
providing more info (for APIs that want to). Or is there a problem with it
that I also missed?

Terry



On Fri, Jun 21, 2013 at 3:30 PM, <exarkun at twistedmatrix.com> wrote:

> On 10:26 am, terry at jon.es wrote:
>
>> Hi Tom
>>
>>> Since most apis in twisted don't pass a canceller, the behavior is a2+a3.
>>>
>>
>> Right. That was the intention (glyph's). It was expected that over time
>> more Twisted apis that create deferreds would add cancellers. As I
>> understand it, Kai Zhang is now adding cancellers to some apis returning
>> deferreds, starting with the POP3 client.
>>
>> Based on JP's comment, I still think I'm missing something here.
>>
>> The only suggestion I've been making is that, if we wanted to, we could
>> allow a value to be passed to the cancel call. That would allow errback
>> functions to receive more information when a Deferred is canceled. You'd
>> still get a CancelledError in any case, but the value would be in the
>> exception instance as args[0], as in
>>
>
> An idea very much like this was discussed when Deferred cancellation was
> being implemented.  My recollection is that it was ultimately explicitly
> rejected, though I don't remember why nor do I find discussion of it on the
> ticket (#990) (lack of this information somewhere seems like a failure of
> the development process).  I admit the idea of being able to get additional
> information passed through the system seems appealing to me, but *not*
> having any additional information does simplify the interface.  Considering
> how much trouble people already have with Deferreds without even bringing
> cancellation into play, maybe the simpler interface is a good thing.
>
> My earlier point was that any Deferred for which cancellation is not
> already explicitly implemented already has a cancellation behavior: it will
> fire its errback chain with `CancelledError`.  It is an incompatible change
> to replace this with a different exception type - such as `ConnectionDone`.
>
> This is slightly different than your suggestion, Terry, I think - in that
> you propose sticking more information onto the `CancelledError`, not
> changing the type of the `Failure` that is sent down the errback chain.
>  However, the thread was started specifically with the question of whether
> changing `CancelledError` to `ConnectionDone` is acceptable and that's the
> point I was mainly focused on.
>
>
> Jean-Paul
>
> ______________________________**_________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.**com <Twisted-Python at twistedmatrix.com>
> http://twistedmatrix.com/cgi-**bin/mailman/listinfo/twisted-**python<http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-python/attachments/20130621/f197046c/attachment.html>