<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 27 Dec 2016, at 13:43, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Imho this is no problem:</div><div class="">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 class=""></div><div>True, but for me it's more about knowing what a method can throw; currently to know that you need to consult documentation which, while fine, isn't the best way to do that when the compiler could know and it'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><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><span class="" style="font-family: Monaco;">myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }</span></blockquote></div>Imho to much confusion with no real benefit:<div class="">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 class=""></div><div>Partly, but it's really just intended to distinguish things that are genuine runtime errors, versus things that shouldn't have happened, i.e- an illegal argument type error shouldn't occur if you're using a method correctly, so it'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'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><br class=""></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><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">One thing to note with explicit errors is that we'd basically introduce sum types…</div></div></blockquote></div><br class=""><div class="">Not necessarily; you could think of explicit errors as being doing something like:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>enum MyErrorType {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case io_error(IOError)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case illegal_argument(IllegalArgumentError)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case unknown(Error)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class="">i.e- boilerplate we could do right now, but would prefer not to, but still allowing it to be handled as an enum.</div></body></html>