<div dir="ltr"><font color="#000000" face="Helvetica">Hi,</font><div><font color="#000000" face="Helvetica"><br></font></div><div><font color="#000000" face="Helvetica">Sounds like checked exceptions of Java with a similar syntax. With Java you have to specify the exceptions a method can throw. However been lots of debate over the years whether it's a good thing or bad thing, some like it, but I think many more hate it.</font></div><div><font color="#000000" face="Helvetica">Most other languages don't have it, and possibly for good reason.</font></div><div><font color="#000000" face="Helvetica"><br></font></div><div><font color="#000000" face="Helvetica">Regards,</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 26, 2016 at 5:43 PM, Rod Brown via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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><div>(resent for Swift Evolution)</div><div><br></div><div>I’m a big fan of this idea. Currently “throws” seems like a very limited API - you know it’s throwing out something, but you can only hope to guess what that is or create fallbacks. Definitely a big +1 from me. A fallback for compatibility could be “throws” assumes “throws Any” and can be a warning?</div><div><br></div><div>While I am not deeply familiar with the implications, I do like think your line of reasoning has merit, and think this makes sense for Phase 1 of Swift 4. </div><div><br></div><div>- Rod</div></div><div><br></div><br><div><blockquote type="cite"><div><div class="h5"><div>On 27 Aug 2016, at 1:39 AM, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div class="h5"><div style="word-wrap:break-word">Hi all,<div><br></div><div>Currently, a function that throws is assumed to throw anything. There was a proposal draft last December to restrict that. The general idea was that you'd write, for instance:</div><div><br></div><div></div><blockquote type="cite"><div>enum Foo: ErrorProtocol {</div><div> case bar</div><div> case baz</div><div>}</div><div><br></div><div>func frob() throws Foo {</div><div> throw Foo.bar // throw .bar?</div><div>}<br></div></blockquote><div><br></div>If you `catch Foo` (or every case of Foo), now that the compiler can verify that your catch is exhaustive, you no longer have to have a catch-all block at the end of the sequence.<br><div><br></div>This impacts the metadata format and has implications on resilience, which leads me to believe that the discussion could qualify for the phase 1 of Swift 4. If this is the case, I'd be interested in pulling out the old discussions and seeing where we left that at.<br><div><div>
<br><span style="font-family:'Lucida Grande';font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Félix</span>
</div>
<br></div></div></div></div>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>