On Tue, Jun 18, 2013 at 8:22 PM, Glyph <gl...@twistedmatrix.com> wrote:
> 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. > Doesn't that mean we'll have many subclasses that mean that something was cancelled? If I didn't take backwards compatibility into account, I would say that composing the original exception into a new CancellationError (or something) exception would be preferable. Would you agree that it would be preferable? (Again, not taking compatibility into account -- I'm trying to get compatibility vs niceness of API to face off against each other. Personally, I think it's enough of a change in functionality to warrant a chance in ways a function can fail, but there's no point in even having that argument if there's no consensus that the composed way would even be better...) > After all, if it's interesting that the operation was cancelled, > presumably it's interesting *at what stage* the operation is cancelled. > IIUC that would work the same with composition as inheritance :) cheers lvh
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
