<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 7, 2016, at 10:13 AM, Jens Alfke <<a href="mailto:jens@mooseyard.com" class="">jens@mooseyard.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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 8:37 AM, Don Wills 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="">IMO, Java has it right - let the API designer decide which approach to take. </span></div></blockquote><div class=""><br class=""></div><div class="">One more time: Swift does not have exceptions at all (checked or not). You are comparing apples and oranges here, based on a surface similarity in syntax (keywords like “try” and “catch”), which indicates you haven’t paid attention to what the actual semantics are. If you want to make credible arguments about error handling, you’ll need a better understanding of it.</div><div class=""><br class=""></div><div class="">I note that Go — a language you profess to like a lot — has no exceptions either, and its error handling support is much more primitive and clumsy to use than Swift’s. (I say this having spent about a man-year coding in Go.)</div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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="">The Swift designers attitude of "we know best, do it the way we tell you" will not play well with many programmers. </span></div></blockquote></div><br class=""><div class="">Go is pretty much the ultimate in that philosophy — Rob Pike and others are very up-front that they know what features are best and they will decide the right way to do things and if you disagree you are wrong. (Pike’s blog post about error handling from about a year ago is a great example of this arrogance.) I see the Swift developers being a lot more open about this, instituting a very open process for proposing and debating changes.</div><div class=""><br class=""></div><div class="">—Jens</div></div></div></blockquote></div><br class=""><div class="">Yes, I recognize that the "my way or the highway" attitude is issue among many language designers today. But, IMO, the dictators at Go made a few better decisions.</div></body></html>