<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 8, 2016, at 10:28 PM, Don Wills via swift-users &lt;<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Jens -<div class=""><br class=""></div><div class="">I apologize for having annoyed you, but this thread has been very informative for me.<div class=""><br class=""></div><div class="">I was under the misconception that Swift was more similar to Java and .NET than to C, C++ and Obj-C. &nbsp;Your statement -&nbsp;<b class="">The designers of Swift do not like exceptions.</b>&nbsp;- clears up some of my misunderstanding of fundamental principles guiding Swift design. &nbsp;And thank you Brent Royal-Gordon - your explanation was of great help in furthering my understanding of those design decisions.</div></div></div></div></blockquote><br class=""></div><div>Hi Don,</div><div><br class=""></div><div>The other folks on this thread are essentially correct, though the tone wasn’t always helpful. &nbsp;It strikes me that you may not have seen the error handling rationale document. &nbsp;If that is the case, you should take a look, it describes many of these tradeoffs, including a number of specific mentions of the Java model and why we decided to go with something different:</div><div><a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst" class="">https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst</a></div><div><br class=""></div><div>Overall, I think the Swift model has worked out really well. &nbsp;The only thing that I’m aware of that we’re seriously considering changing is to allow the ability to throw a single specific error type, instead of having type erasure take it all away. &nbsp;This is blocked on the resilience work landing, but it would be great to see it get implemented shortly after that.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>