On Jun 20, 2013, at 12:34 PM, exar...@twistedmatrix.com wrote:
> Thank you for pointing this out. It seems like an important fact that makes
> the rest of the discussion moot.
>
> By making `Deferred.cancel` work on any Deferred by triggering a
> `CancelledError`, we have already decided on the failure behavior for all
> existing Deferred-returning APIs. Changing that at this point doesn't seem
> like a very good idea.
>
> I think I'd also like to challenge the idea that Glyph put forwards earlier
> in the thread that this extra information is *necessarily* important to the
> application.
These are all pretty good points.
In fact, I think I'm going to withdraw my suggestion. Having better ways to
classify errors would be useful in some circumstances, but it's demonstrably
not *necessary*, and a system to arbitrarily classify every single cancellation
that any Deferred might raise (not to mention documentation of how to make use
of all this information).
So I will save any further words I might write in this thread for narrative
documentation for cancellation :).
-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
