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

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Fri Jun 21 13:35:39 MDT 2013


On 03:42 pm, terry at jon.es wrote:
>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?

I think technically that would solve the problem.  It sounds like a bit 
of a nightmare though.  But that's what we get for using types to 
indicate error conditions, I suppose?

Cancellation is still new, and I don't think many people are using it 
yet (how could they, since no one has bothered to write any 
documentation for it).  I suspect different people probably also have 
different ideas about how it *should* be used - and so we've probably 
all started to go off in somewhat different directions, which is going 
to result in disagreement in what practices are best.

I think the best possible next step here is to actually document what 
it's already possible to do with cancellation (I think there are several 
non-obvious tricks - mainly in the area of asynchronous cancellation, a 
feature not *explicitly* supported by the API, but still possible). 
After that, perhaps we'll be able to see what it's *not* possible to do 
and then a discussion about how to fill in the gaps in functionality 
will be a lot easier to have.

Jean-Paul



More information about the Twisted-Python mailing list