<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 18, 2013 at 8:22 PM, Glyph <span dir="ltr"><<a href="mailto:glyph@twistedmatrix.com" target="_blank">glyph@twistedmatrix.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div dir="auto">

</div></div></blockquote><div><br></div><div>Doesn't that mean we'll have many subclasses that mean that something was cancelled?<br><br>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...)<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto">After all, if it's interesting that the operation was cancelled, presumably it's interesting <i>at what stage</i> the operation is cancelled.</div>

</div></blockquote><div><br></div><div>IIUC that would work the same with composition as inheritance :)<br><br><br></div><div><font color="#888888">cheers<br>lvh<br></font></div><div style="word-wrap:break-word"> <span class="HOEnZb"></span><br>

</div></div></div></div>