<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="">I like checked exceptions in Java so I'd be in support of this, as I feel it's a helpful feature to ensure that exceptions are properly handled.</div><div class=""><br class=""></div><div class="">I never really understood the complaints against it, as you're still free to just use a generic catch block for "everything else", and we have things like try? and try! when you don't expect an exception and just want to keep things simple, so the situation is already easier than in Java.</div><div class=""><br class=""></div><div class="">I'd say that there should still be generic "could throw anything" variant, like throws ErrorProtocol or such, but in most cases a well-defined error type (or several types?) is best, as developers should really think about what types of errors they produce and how someone might handle them when designing a method, and users of the method should be thinking about how they can recover from an error if it occurs, or fail in a more graceful/informative manner if they can't. Currently I don't think Swift's untyped throws achieve that.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 26 Aug 2016, at 17:01, Nur Ismail via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><font face="Helvetica" class="">Hi,</font><div class=""><font face="Helvetica" class=""><br class=""></font></div><div class=""><font face="Helvetica" class="">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 class=""><font face="Helvetica" class="">Most other languages don't have it, and possibly for good reason.</font></div><div class=""><font face="Helvetica" class=""><br class=""></font></div><div class=""><font face="Helvetica" class="">Regards,</font></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Aug 26, 2016 at 5:43 PM, Rod Brown via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="">(resent for Swift Evolution)</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">- Rod</div></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On 27 Aug 2016, at 1:39 AM, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><div style="word-wrap:break-word" class="">Hi all,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">enum Foo: ErrorProtocol {</div><div class=""> case bar</div><div class=""> case baz</div><div class="">}</div><div class=""><br class=""></div><div class="">func frob() throws Foo {</div><div class=""> throw Foo.bar // throw .bar?</div><div class="">}<br class=""></div></blockquote><div class=""><br class=""></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 class=""><div class=""><br class=""></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 class=""><div class=""><div class="">
<br class=""><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" class="">Félix</span>
</div>
<br class=""></div></div></div></div>______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""></div></blockquote></div><br class=""></div><br class="">______________________________<wbr 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/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<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>