<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 6, 2016, at 1:12 PM, Don Wills <<a href="mailto:don.wills@portablesoftware.com" class="">don.wills@portablesoftware.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; 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; float: none; display: inline !important;" class="">It also means that every third party API provider will *never* be able to change any method signature from failable to non-failable or vice-versa. That is a really bad thing!</span></div></blockquote><br class=""></div><div>API consistency is a good thing. A method that can fail is fundamentally different than the same method without failure — it’s comparable to adding another return value, or an ‘out’ parameter, both of which we would expect to be a breaking API change. Sneaking in unchecked exceptions is like saying “oh yeah, starting in version 3.5, calling this method might suddenly abort your flow of control and take you to back the nearest catch block, even though you didn’t think it could do that. I hope that’s not a problem.” (Reminds me of the way PHP introduces catastrophic API behavior changes under the hood in minor releases…)</div><div><br class=""></div><div>If you do end up needing to add errors to an API method, you can do it by adding a new variant of the method that throws, deprecating the old version, and then removing the old one once clients have migrated.</div><div><br class=""></div><div>—Jens</div></body></html>