<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 11:40 AM, Jeremy Pereira via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</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="">In Swift, you throw errors, not exceptions. The word exception is (more or less) reserved for conditions that terminate the process.<span class="Apple-converted-space"> </span></span><br 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;" class=""><br 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;" 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="">There are no unchecked errors but then why would you not want to handle an error condition if it occurs? Why would you not want to know that an API can throw an error?</span><br 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;" class=""></div></blockquote></div><br class=""><div class="">The bigger point is that <b class="">in Swift you always know at the call site whether something can fail</b>. That is, you can see the possible flows of control by inspecting the code. </div><div class=""><br class=""></div><div class="">Consider this block of code:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>{ foo(); bar(); endFoo(); }</div><div class="">If foo is called, will endFoo() also be called? </div><div class=""><br class=""></div><div class="">In C++/Java/C# it’s not possible to tell without doing extensive analysis of the implementation of bar (and everything that bar calls), because bar might throw an exception and derail this flow of control. (And worse, some later code change far away might add an unchecked exception, making your analysis wrong!) This then requires adding noise in the form of a ‘finally’ block or a helper class implementing RAII, if it’s really important that endFoo be called. In a lot of cases this is “too much trouble” so a lot of code gets left like above, and will break some invariant if the endFoo call gets skipped.</div><div class=""><br class=""></div><div class="">In Swift you can be sure that, if this block is entered, all three functions will be called. (Unless the process hits a fatal exception like an assertion failure or bus error and exits.) If it’s possible for bar to fail, then</div><div class="">(a) the call to bar will have to be prefixed with ‘try’, which is a yellow flag to the programmer noting the possibility*; and</div><div class="">(b) the block will have to be inside a `do … catch` block, in the same function, to handle the error. An error in bar() can’t just abort the function silently. Any cleanup that has to be done will be explicit.</div><div class=""><br class=""></div><div class="">—Jens</div><div class=""><br class=""></div><div class="">* The requirement of the ‘try’ prefix means that if a function that isn’t failable later gets modified to be failable, every call site will now trigger a compile error due to the missing ‘try’ keyword. This means the programmer who made the change will have to go through the codebase and consider the possibility of failure and adjust the call site accordingly. This is a really good thing!</div></body></html>