<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="">On Jan 3, 2016, at 6:36 PM, Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><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=""><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="">I agree that requiring this is not likely to result in improved error handling and thus is not a strong argument in favor of it.<br class=""><br class="">IMO the purpose of requiring “try” to be stated explicitly is that it arguably makes code more readable. &nbsp;It is immediately clear which functions can throw and which cannot. &nbsp;You don’t need to look up the signature of every function called to determine this. My experience thus far has been that I have really appreciated the requirement that throwing expressions be explicitly marked.<span class="Apple-converted-space">&nbsp;</span><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="">As a default it’s great. &nbsp;Not having a way to opt out of individual marking for a whole block or function—because you know you’re not breaking any invariants, so which functions can throw is irrelevant, and not having a way for the compiler deduce these regions (e.g. known pure functions)—is the problem. &nbsp;The recognizer code posted in an earlier message is a perfect example. &nbsp;If there *was* some code where it was really important to notice failure points, you’d miss it.<span class="Apple-converted-space">&nbsp;</span></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=""></div></blockquote><div class=""><br class=""></div><div class="">I feel like I must be missing something here. &nbsp;If we are able to mark the whole block with try I don’t see how we would notice any really important failure points. &nbsp;They would not be marked anywhere in the source:</div><div class=""><br class=""></div><div class="">&nbsp; func recognizeHandler() throws {</div><div class="">&nbsp; &nbsp; try {</div><div class="">&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="">&nbsp; &nbsp; &nbsp; &nbsp; recognizeName()<br class="">&nbsp; &nbsp; &nbsp; &nbsp; recognizeFormalParamSeq()<br class="">&nbsp; &nbsp; &nbsp; &nbsp; accept(.newline)<br class="">&nbsp; &nbsp; &nbsp; &nbsp; recognizeCommandSeq()<br class="">&nbsp; &nbsp; &nbsp; &nbsp; accept(.end)<br class="">&nbsp; &nbsp; &nbsp; &nbsp; recognizeName() &nbsp;&nbsp;&nbsp;// Later Visitor pass checks that names match.&nbsp;<br class="">&nbsp; &nbsp; &nbsp; &nbsp; accept(.newline)</div><div class="">&nbsp; &nbsp; }</div><div class=""><div class=""><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""></blockquote>&nbsp;&nbsp;}</div></div></div></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">Indeed. &nbsp;Also, FWIW, I’d argue that maybe the root problem here is that this code should not be using Swift’s error handling constructs in the first place. &nbsp;An enum (or other approach) may be more appropriate. &nbsp;Swift’s error handling design is intentionally driven by the idea that you shouldn’t use it if “everything throws” - in this situation, the sugar benefits of error handling are intentionally outweighed by the weight of the try keywords everywhere. &nbsp;This is meant to force the balance over to using more manual techniques.</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>