<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 Jan 3, 2016, at 10:51 AM, David Waite &lt;<a href="mailto:david@alkaline-solutions.com" class="">david@alkaline-solutions.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">In a block of code where errors are only thrown in some places, do+try is illustrative because it allows you to know which functions are possible failure points.</div><div class=""><br class=""></div><div class="">However, in a block of code where errors are thrown in most places, a try block would be useful because individual try statements become noise.</div></div></div></blockquote><div><br class=""></div>Whether the individal failure points are important to notice is not related to how many of them there are; it’s a function of what your code is doing in between and around them.&nbsp;</div><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=""></div><div class="">Comments:</div><div class="">1. I was under the impression that the second case was not expected to be the norm in swift code when the error functionality was added.</div></div></div></blockquote><div><br class=""></div>That seems unlikely there is a large class of common applications that fall into that bucket. &nbsp;In particular, anything likely to be coupled to I/O tends to be like that.</div><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="">2. It seems like in either case, a try block would be less typing than a do+try block. I don’t know if this would lead to do blocks not being used in cases where doing so would improve code comprehension.</div><div class=""><br class=""></div><div class="">3. Using try in this manner also has the potential (positive and negative) of having c++ style try/catch, but with different mechanics (as we are dealing with errors and not exceptions).</div><div class=""><br class=""></div><div class="">One possible approach if it was desirable to not have this used arbitrarily in place of do+try, and to avoid looking too much like exception syntax: instead define rethrows blocks:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote>&nbsp; func recognizeHandler() throws {</div><div class="">&nbsp; &nbsp; &nbsp; rethrows {<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;accept(.on) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// .on is an enum tag for the token for the ‘on’ keyword.<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote>&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;recognizeName()<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote>&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;recognizeFormalParamSeq()<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote>&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;accept(.newline)<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote>&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;recognizeCommandSeq()<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote>&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;accept(.end)<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote>&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;recognizeName() &nbsp;&nbsp;&nbsp;// Later Visitor pass checks that names match.&nbsp;<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote>&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;accept(.newline)</div><div class="">&nbsp; &nbsp; &nbsp; }<br class="">&nbsp;&nbsp;}</div><div class=""><br class=""></div><div class="">A rethrows block does not allow catch blocks to be attached.</div></div></div></blockquote><div><br class=""></div><div>Sure; I wanted that to be the meaning of the “rethrows” keyword that adorns a func decl, so it didn’t cause an extra level of indentation. &nbsp;A very common case is, “I am not directly throwing any errors of my own; I promise to only propagate errors thrown by my parameters (including generic parameters), and it doesn’t matter which of them throws.”&nbsp;</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="">To catch any of the errors, you would still need to use do+try, which means do+try would still be used in cases where it was illustrative. There is an extra level of indentation, but at four character indentation this would not make the lines of code any longer (since you eliminated “try “). There is no syntax mismatch with existing languages with exception semantics to cause confusion.</div><div class=""><br class=""></div><div class="">Comments?</div><div class=""><br class=""></div><div class="">-DW</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 3, 2016, at 10:58 AM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Jan 3, 2016, at 2:08 AM, Andrew Duncan via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">There are large classes of programs where you can know you don’t care exactly where a failure happens, e.g. (most init functions, all pure functions, any function that doesn’t break invariants). &nbsp;In these cases marking every statement or expression that can throw is just noise. &nbsp;Try writing some serialization/deserialization code where the underlying stream can fail to see what I mean; you’ll have “try” everwhere, and it adds nothing to comprehensibility or maintainability. &nbsp;Personally I would like to be able to label the function itself and not have to introuce a scope, but IMO being able to create “try blocks” would be a welcome addition and would even match the common case in blocks with catch clauses, where being aware of the exact line where the error was generated is typically not useful.<br class=""></blockquote><br class="">That's a really interesting idea, but I don't think it's what the poster was suggesting. It sounded to me like he was merely saying “let's make the Swift error system look like my favorite language's exception system".<br class=""></blockquote><br class="">I agree with Brent’s assessment of the OP. However that doesn’t mean that Dave does not have a good point. Here is some code from a recursive descent parser. (More correctly: the recognizer. Omitting the AST-building stuff.)<br class=""><br class="">&nbsp;&nbsp;func recognizeHandler() throws {<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try accept(.on) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// .on is an enum tag for the token for the ‘on’ keyword.<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try recognizeName()<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try recognizeFormalParamSeq()<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try accept(.newline)<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try recognizeCommandSeq()<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try accept(.end)<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try recognizeName() &nbsp;&nbsp;&nbsp;// Later Visitor pass checks that names match.<span class="Apple-converted-space">&nbsp;</span><br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try accept(.newline)<br class="">&nbsp;&nbsp;}<br class=""><br class="">There is a lot more where that came from.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Exactly. &nbsp;The natural response from framework designers is to find more ways to support writing entire functions as a single expression. &nbsp;At the limit, you end up with<span class="Apple-converted-space">&nbsp;</span></span><a href="http://www.boost.org/doc/libs/1_60_0/libs/phoenix/doc/html/phoenix/modules/statement.html" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://www.boost.org/doc/libs/1_60_0/libs/phoenix/doc/html/phoenix/modules/statement.html</a><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">-Dave</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""><div class="">
-Dave

</div>
<br class=""></body></html>