<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 class=""><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 3:56 PM, Jens Alfke <<a href="mailto:jens@mooseyard.com" class="">jens@mooseyard.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 2:33 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=""><div class="" style="font-family: Alegreya-Regular; font-size: 15px;">Do you really believe that you can stop the "users" who "loathed them so much" from doing what they want to do with Swift? Hubris isn't a strong enough word to describe that attitude.</div></div></blockquote><div class=""><br class=""></div><div class="">It’s impossible to implement unchecked exceptions in Swift because it lacks any form of stack-unwinding. For example, if A calls B calls C, and B is not marked as ‘throws’, then there is no way for C to return an error back to A. (Unless the error is stored externally, like as an object property, instead of being directly returned.)</div></div></div></div></blockquote><div><br class=""></div><div>Actually, that is circular logic. "It is impossible to do A in B because B lacks the thingies necessary to do A." Regardless of that twisted logic, of course Swift could have implemented the stack unwinding stuff. Such support is an integral feature of LLVM. See <a href="http://llvm.org/docs/ExceptionHandling.html#exception-handling-intrinsics" class="">http://llvm.org/docs/ExceptionHandling.html#exception-handling-intrinsics</a></div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="" style="font-family: Alegreya-Regular; font-size: 15px;">FWIW, I've already started down the path of dealing with the lack of unchecked <whatever-you-call-em>s by using the following code:</div></blockquote><br class=""></div><div class="">“try!” isn’t anything like an unchecked exception. It simply <i class="">ignores</i> the error. It’s the equivalent of the unfortunate Java idiom:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>try {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>somethingThatMightThrowAnException();</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>} catch(Exception e) { /* la la la I can’t hear you */ }</div><div class="">Back in my Java days I tracked several mysterious bugs down to usage of this idiom. Internally something was failing, but the exception was ignored so there was no indication of the failure. That made it much harder for me to find.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="font-family: Alegreya-Regular;"><font face="Courier New" class=""><b class=""> throw Exception("Invalid type") /* for those types not supported which is a programmer error */</b></font></div></blockquote><div class=""><div class="" style="font-family: Alegreya-Regular;"><font face="Courier New" class=""><b class=""><br class=""></b></font></div></div></div><div class="">The correct way to signal a programmer error in Swift is with assert() or fatalError() [sp?]. Which removes your need to use the above workaround, because the method no longer needs to be marked as throws.</div></div></blockquote><div><br class=""></div><div>assert() is of no use because it disappears if optimization is turned on. And fatalError() is also of no use for complex, multi-threaded systems like HTTP servers - systems in which a thread can croak but that you don't want to take down the entire process.</div></div><div class=""><br class=""></div></body></html>