<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 Dec 7, 2015, at 5:24 PM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.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="">You enable assertions for release builds then? </span></div></blockquote><div><br class=""></div><div>It depends on the target. In a lot of app-level code it doesn’t make much difference to leave them in, while in lower-level performance-sensitive code it’s a big slowdown. (Back when I worked at Apple, a lot of system apps shipped with assertions enabled.)</div><div><br class=""></div><div>But that’s irrelevant. If you had to add a ‘throws’ declaration to a function to add error handling to it in debug builds, it’s still going to have the overhead of ‘throws’ in a release build even if the error check is suppressed somehow.</div><br class=""><blockquote type="cite" class=""><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="">Remember, I'm talking specifically about library code: the same way that calling NSArray's objectAtIndex throws an exception (if my memory serves well) for out of bounds indices. At least, NSAssert in Objective-C throws exceptions and is catchable.</span></div></blockquote></div><div class=""><br class=""></div>(a) Obj-C exceptions (which are bridged to C++ exceptions) don’t incur any overhead, unlike Swift ‘throws’ functions. They have no direct equivalent in Swift.<br class=""><div class="">(b) You’re not _supposed_ to catch NSAssertion failures, or at least not let your app continue afterwards. Cocoa has always had a weird ambivalence about exceptions: they’re part of the Obj-C language, but their use is discouraged, and the docs have become increasingly direct about telling you not to catch-and-continue.</div><div class=""><br class=""></div><div class="">—Jens</div></body></html>