<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 18, 2013, at 2:13 PM, Itamar Turner-Trauring <<a href="mailto:itamar@itamarst.org">itamar@itamarst.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 06/18/2013 02:22 PM, Glyph wrote:<br><blockquote type="cite">Making an API that previously documented raising (or failing) exception types A, B, and C raise (or fail with) D is not necessarily a compatible change. Making it raise (or fail with) A' (a subclass of A) is, though.<br><br></blockquote>The API for pop3client does *not* document the expected exceptions, so backwards compatibility isn't really an issue here.<br></div></blockquote></div><br><div>Hrm. I would say that if you don't document exceptions, then you just have to support whatever your behavior was before :).</div><div><br></div><div><a href="http://twistedmatrix.com/trac/wiki/CompatibilityPolicy">http://twistedmatrix.com/trac/wiki/CompatibilityPolicy</a> does not explore this issue, though.</div><div><br></div><div>-glyph</div><div><br></div></body></html>