
<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><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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 class=""><br class=""></div><div class="">True, but for me it's more about knowing what a method can throw</div></div></div></div></blockquote><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><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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 class=""><br class=""></div><div class="">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><div>That reminds me to much on the route Java took...</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=""><div class="">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>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></body></html>