On Jun 18, 2013, at 12:03 PM, Laurens Van Houtven <_...@lvh.io> wrote:
> 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...) I agree that it would be preferable, but I don't see how it's possible without making Exception itself composeable. > 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 :) Unfortunately inheritance is built into the way Python handles exceptions. In fact in this case you almost want *multiple* inheritance, so you can say 'except CancelledError:' or 'except ConnectionError:' as appropriate. :-( The one saving grace here is that not a whole lot of useful logic can live on the exception objects, so there's a limited amount of opportunity for getting oneself into trouble. Please prove me wrong, though. -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
