<div dir="ltr">On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho 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><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I suppose &quot;throws&quot; could be enhanced to produce a compiletime enum <br><br>func bar() throws {<br>throw NSError()<br>throw MyEnumError.firstError<br>}<br><br>Under the hood each expression passed to &quot;throw&quot; could make something like<br><br>enum bar_abcdefj_throw {<br>case genericError // all NSError go here<br>case MyEnumErrorFirstError<br>}<br><br>Where abcdefj is unique characters.<br> <br><br>This enum would only be visible through the catch blocks which would act like a switch statement.<br><br>Speaking of switch statements do they currently support &quot;try&quot; expressions?<br><br>switch try foo() {<br>case .MyEnumErrorFirstError:<br>// handle error<br>default: <br>// handle NSError and everything else<br>}<br></blockquote><div><br></div><div>If I&#39;m not mistaken, `switch try foo()` switches over the return value of foo(); you&#39;d switch over the error in a catch block.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The benefit of this approach is that it would be additive. And no source breakage.<br><br>At the risk of being off topic if there is interest in this I can start a new thread for this.<div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 27, 2016 at 9:54 AM Haravikk &lt;<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</a>&gt; wrote:<br></div><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="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg"><blockquote type="cite" class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg">On 27 Dec 2016, at 13:43, Tino Heth &lt;<a href="mailto:2th@gmx.de" class="m_2322409923842249406gmail_msg" target="_blank">2th@gmx.de</a>&gt; wrote:</div><div class="m_2322409923842249406gmail_msg"><div style="word-wrap:break-word" class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg">Imho this is no problem:</div><div class="m_2322409923842249406gmail_msg">Right now, we basically have &quot;throws Error&quot;, and no matter what is actually thrown, we can always catch exhaustive by keeping the statement unspecific.</div></div></div></div></blockquote><div class="m_2322409923842249406gmail_msg"><br class="m_2322409923842249406gmail_msg"></div></div></div><div style="word-wrap:break-word" class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg">True, but for me it&#39;s more about knowing what a method can throw; currently to know that you need to consult documentation which, while fine, isn&#39;t the best way to do that when the compiler could know and it&#39;s then up to you whether to let it auto-complete for all throwable types, or just be generic for some or all of them (or pass the buck).</div></div></div><div style="word-wrap:break-word" class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg"><br class="m_2322409923842249406gmail_msg"><blockquote type="cite" class="m_2322409923842249406gmail_msg"><div style="word-wrap:break-word" class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg"><blockquote type="cite" class="m_2322409923842249406gmail_msg"><span style="font-family:Monaco" class="m_2322409923842249406gmail_msg">myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }</span></blockquote></div>Imho to much confusion with no real benefit:<div class="m_2322409923842249406gmail_msg">Shouldn&#39;t it be up to the caller to decide which errors need special treatment? The library can&#39;t enforce proper handling at all.</div></div></blockquote><div class="m_2322409923842249406gmail_msg"><br class="m_2322409923842249406gmail_msg"></div></div></div><div style="word-wrap:break-word" class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg">Partly, but it&#39;s really just intended to distinguish things that are genuine runtime errors, versus things that shouldn&#39;t have happened, i.e- an illegal argument type error shouldn&#39;t occur if you&#39;re using a method correctly, so it&#39;s more like something you might check as an assertion. I should have been more clear that the main difference is in how fix-its might recommend the errors are handled; specific types would produce catch blocks, but optionals might be grouped into a catch-all at the end (e.g- they&#39;re special interest that you might not be bothered about), but the compiler would still be aware of them should you decide to add them.</div><div class="m_2322409923842249406gmail_msg"><br class="m_2322409923842249406gmail_msg"></div><div class="m_2322409923842249406gmail_msg">If the distinctions not significant enough though then the &quot;optional&quot; error types could just be ignored for now, I think the more important ability is the ellipsis indicating &quot;plus other errors&quot; 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><div style="word-wrap:break-word" class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg"><br class="m_2322409923842249406gmail_msg"><blockquote type="cite" class="m_2322409923842249406gmail_msg"><div style="word-wrap:break-word" class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg">One thing to note with explicit errors is that we&#39;d basically introduce sum types…</div></div></blockquote></div></div><div style="word-wrap:break-word" class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg"></div><br class="m_2322409923842249406gmail_msg"><div class="m_2322409923842249406gmail_msg">Not necessarily; you could think of explicit errors as being doing something like:</div><div class="m_2322409923842249406gmail_msg"><br class="m_2322409923842249406gmail_msg"></div><div class="m_2322409923842249406gmail_msg"><span class="m_2322409923842249406m_7179559898482663862Apple-tab-span m_2322409923842249406gmail_msg" style="white-space:pre-wrap">        </span>enum MyErrorType {</div><div class="m_2322409923842249406gmail_msg"><span class="m_2322409923842249406m_7179559898482663862Apple-tab-span m_2322409923842249406gmail_msg" style="white-space:pre-wrap">                </span>case io_error(IOError)</div><div class="m_2322409923842249406gmail_msg"><span class="m_2322409923842249406m_7179559898482663862Apple-tab-span m_2322409923842249406gmail_msg" style="white-space:pre-wrap">                </span>case illegal_argument(<wbr>IllegalArgumentError)</div><div class="m_2322409923842249406gmail_msg"><span class="m_2322409923842249406m_7179559898482663862Apple-tab-span m_2322409923842249406gmail_msg" style="white-space:pre-wrap">                </span>case unknown(Error)</div><div class="m_2322409923842249406gmail_msg"><span class="m_2322409923842249406m_7179559898482663862Apple-tab-span m_2322409923842249406gmail_msg" style="white-space:pre-wrap">        </span>}</div><div class="m_2322409923842249406gmail_msg"><br class="m_2322409923842249406gmail_msg"></div><div class="m_2322409923842249406gmail_msg">i.e- boilerplate we could do right now, but would prefer not to, but still allowing it to be handled as an enum.</div></div></blockquote></div>
</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>