<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="">I see two main use cases for throws right now:<div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">for high-level operations that can fail for a lot of reasons</li><li class="">when it's convenient to bubble out of a complex, nested/recursive algorithm (like parsing a data structure)</li></ul><div class=""><br class=""></div><div class="">Throws works well for case one, but it's not awesome for case two. I don't think that adding an optional type annotation to throws would hurt case one a lot, too.</div><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 29 août 2016 à 21:13:51, Russ Bishop <<a href="mailto:xenadu@gmail.com" class="">xenadu@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Aug 26, 2016, at 8:39 AM, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hi all,<br class=""><br 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:<br class=""><br class=""><blockquote type="cite" class="">enum Foo: ErrorProtocol {<br class=""> case bar<br class=""> case baz<br class="">}<br class=""><br class="">func frob() throws Foo {<br class=""> throw Foo.bar // throw .bar?<br class="">}<br class=""></blockquote><br class="">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=""></blockquote><br class="">This contract is a lie in almost all real-world programs because real programs talk to the network, the filesystem, the database, etc and the class of errors that can be thrown is tremendous. The number of functions where “throws Foo” is an improvement and Foo is not an exhaustive list of “throws HTTPError, NetworkError, StorageError, DatabaseError, MachPortError, …” is close enough to zero to be considered zero. This ultimately leads to library authors merely wrapping exceptions using generic catch-all blocks anyway, adding no useful information.<br class=""><br class="">There is zero value to adding it without the compiler enforcing it because you can only omit default catch blocks safely when you can be certain the list of exceptions is exhaustive.<br class=""><br class="">I am sympathetic to the default/generic catch block problem but we could certainly solve that with some added syntax or automatic insertion of a rethrow if an error doesn’t match, meaning any function with a try{} and no default catch must itself be a throwing function.<br class=""><br class=""><br class=""><br class="">Since this isn’t applicable to Swift 4 phase 1 I’ll hush now :)<br class=""><br class="">Russ<br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>