<div dir="ltr">Then let&#39;s change my response to simply: :+1:<div><br></div><div>Thanks!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 11:28 AM, David Owens II <span dir="ltr">&lt;<a href="mailto:david@owensd.io" target="_blank">david@owensd.io</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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>recoverable</i> errors. </div><div><br></div><div>I’m perfectly fine with allowing:</div><div><br></div><div><font face="Menlo">func foo() throws -&gt; () {}</font></div><div><br></div><div>And</div><div><br></div><div><font face="Menlo">func foo() throws MyError -&gt; () {}</font></div><div><br></div><div>The proposal states that.</div><div><br></div><div>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><span class="HOEnZb"><font color="#888888"><div><br></div><div>-David</div></font></span><div><div class="h5"><br><div><blockquote type="cite"><div>On Dec 7, 2015, at 4:06 PM, Andrew Bennett via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr">Isn&#39;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><br></div><div>Default syntax:</div><div>func foo() throws; // defaults to ErrorType</div><div><br></div><div>Optional type safety:</div><div>func foo() throws(MyError); // note, only one type.</div><div><br></div><div>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><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 9:24 AM, Russ Bishop via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">IMHO be careful what you wish for. If the compiler enforces this then we&#39;re just repeating the mistakes of Java&#39;s checked exceptions. All roads would eventually lead to &quot;throws ErrorType&quot;, defeating the supposed purpose.</div><div class="gmail_quote"><br></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">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></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="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">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div>