<div dir="ltr">FYI, here's the December 2015 discussion on typed throws:<div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003284.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003284.html</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 27, 2016 at 4:57 PM, Tino Heth 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><span class=""><blockquote type="cite"><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div>Right now, we basically have "throws Error", and no matter what is actually thrown, we can always catch exhaustive by keeping the statement unspecific.</div></div></div></div></blockquote><div><br></div><div>True, but for me it's more about knowing what a method can throw</div></div></div></div></blockquote></span><div>That's always possible if throw can be annotated with a list of errors; in this case, it's up to the library author to be specific</div><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div style="word-wrap:break-word"><div><blockquote type="cite"><span style="font-family:Monaco">myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }</span></blockquote></div>Imho to much confusion with no real benefit:<div>Shouldn't it be up to the caller to decide which errors need special treatment? The library can't enforce proper handling at all.</div></div></blockquote><div><br></div><div>Partly, but it's really just intended to distinguish things that are genuine runtime errors, versus things that shouldn't have happened,</div></div></div></div></blockquote></span><div>That reminds me to much on the route Java took...</div><span class=""><br><blockquote type="cite"><div style="word-wrap:break-word"><div><div>If the distinctions not significant enough though then the "optional" error types could just be ignored for now, I think the more important ability is the ellipsis indicating "plus other errors" so we can specify either exhaustive lists of error types, or keep them open-ended, in which case the types listed are those that would be placed as catch blocks, with the ellipsis indicating that a catch-all is still required (or throw on the current method).</div></div></div></blockquote></span>That are three levels of error whereas one should be enough — and I'm really not a fan of ellipsis:</div><div>Just require the list to be complete, which can always be achieved by adding Error (or Any — imho we should remove the restriction that throwable types have to conform to an empty protocol).</div><div>In this case, the meaning of the list would be more or less only documentation (it's no restriction on what can be thrown), but that would be fine for me, and it could be used for autocompletion as well.</div></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></div>