<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=""><div class="">Java mixes the ability to catch catastrophic errors with programming errors; that’s part of the problem. Swift’s approach is that the throws construct is for <i class="">recoverable</i>&nbsp;errors.&nbsp;</div><div class=""><br class=""></div><div class="">I’m perfectly fine with allowing:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">func foo() throws -&gt; () {}</font></div><div class=""><br class=""></div><div class="">And</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">func foo() throws MyError -&gt; () {}</font></div><div class=""><br class=""></div><div class="">The proposal states that.</div><div class=""><br class=""></div><div class="">What the typed version allows is the ability specifically validate that all of the error constructs (assuming an enum ErrorType) have been handled. If you still want to use the “catch-all”, that’s fine, you can do so. I’m not proposing to take away your ability to throw any ErrorType conforming type you want to.</div><div class=""><br class=""></div><div class="">-David</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2015, at 4:06 PM, Andrew Bennett via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Isn't it better to have the choice of type safety, and perhaps have a compiler option or linter to enforce it (if you choose).<div class=""><br class=""></div><div class="">Default syntax:</div><div class="">func foo() throws; // defaults to ErrorType</div><div class=""><br class=""></div><div class="">Optional type safety:</div><div class="">func foo() throws(MyError); // note, only one type.</div><div class=""><br class=""></div><div class="">When it comes down to it, for me, the problem is that you can catch anything you like, and the check for exhaustivity does not check what may actually be thrown, resulting in excess code and compile-time errors.</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Dec 8, 2015 at 9:24 AM, Russ Bishop via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">IMHO be careful what you wish for. If the compiler enforces this then we're just repeating the mistakes of Java's checked exceptions. All roads would eventually lead to "throws ErrorType", defeating the supposed purpose.</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote">russ</div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uShB06FGTXMSkgj0zcILepLN1SxfsyIFi84rt4dtPuPvmM-2Btr7bI15-2BUywQZfodHtR1ohtCDOEg7qxC-2F2URXwCOJpzFO8qCwqBi7Hxtt4lkHT5nNgsmuDg8f-2Bzj4dAQQDWxROdOWAKLetq9NUQ-2F-2BEjbFuSIIvD9MqrlCbDDwCeSrvu1z24Vf6lK2cnRPQzoP-2FY-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important" class="">
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43pXkLx-2B36P-2BPNJufHeY0dgdCcMWt8ckx2cHNjnEdI62ujZn-2Fc1xCqhWY5SFDEHQfBXsYiwMh-2FB4Yte-2F0X28qTRXWg1ps7KsHcmkZD7vhM6XIoIsHDF1qZEnPzyBrqQLdB4rVeH9IfglFrDu6zCbUr-2BkawxNGQpOnB444-2BwqtIozxphk2a1TbnC6J9COf-2B6snxQ-3D-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>