<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hello dear Swift community,</div><div><br></div><div>this proposal might seem like some new syntax sugar, but it also aims to escape the '<b>do { }</b>' scope from the '<b>do try catch</b>‘ mechanism while making the existing error handling more powerful.</div><div><br></div><div>Lets assume we have some sort of network type, which can throw a ton of different errors:</div><div><br></div><div><b>struct TCPListener {</b></div><div><span class="Apple-tab-span" style="white-space:pre"><b> </b></span></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>init(address: String) throws { /* implement */ }</b></div><div><b><br></b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>func accept() throws -> TCPConn { /* implement */ }</b></div><div><b><br></b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>/* ... */</b></div><div><b>}</b></div><div><br></div><div>A way of implimentation might look like this:</div><div><br></div><div><b>let listener: TCPListener</b></div><div><b>do {</b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>listener = try TCPListener("some valid address")</b></div><div><b><br></b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>// we could do more work here, but if we need to catch more</b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>// errors we will result in a new PYRAMIDE OF DOOM</b></div><div><b>} catch {</b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>fatalError()</b></div><div><b>}</b></div><div><br></div><div>At this point think about the comment inside the '<b>do { }</b>' scope. Such an application might result in a new pyramide of doom as we know from optional unwrapping before '<b>guard else</b>' mechanism was introduced.</div><div><br></div><div><b>let clientConn: TCPConn</b></div><div><b>do {</b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>clientConn = try listener.accept() // save to call accept method</b></div><div><b>} catch {</b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>fatalError()</b></div><div><b>} </b></div><div><br></div><div>As you can see this application might not need the extra 'do' scope at all, and if it does, the 'do try catch' is still there.</div><div><br></div><div>I propose a new <b>error handling mechanism</b> that mimics the solution for optional pyramide of doom, which adds a slightly better syntax and removes the unneeded/unused '<b>do { }</b>' scope (as for the example from above). Not only can this mechanism guarantee the execution of a throwing function without any errors (like a true guard condition) it also can assign returned values to a new constant/variable.</div><div><br></div><div>Introducing the '<b>guard try catch</b>' mechanism:</div><div><br></div><div><b>guard try throwingFunc() catch { </b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>/* handle error */ </b></div><div><b>}</b></div><div><b><br></b></div><div><b>guard try throwingFunc() catch _ { </b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>/* handle error */ </b></div><div><b>}</b></div><div><b><br></b></div><div><b>guard try throwingFunc() catch pattern { </b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>/* handle error */ </b></div><div><b>}</b></div><div><b><br></b></div><div><b>guard try throwingFunc() catch pattern where condition { </b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>/* handle error */ </b></div><div><b>}</b></div><div><b><br></b></div><div><b>guard let newInstance = try throwingFuncReturns() catch ... { </b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>/* handle error */ </b></div><div><b>}</b></div><div><br></div><div>Where '<b>...</b>' represents the different combinations of possible patterns already showed in the first 4 examples.</div><div><br></div><div>We also might want the return type to be mutable.</div><div><br></div><div><b>guard var newMutableInstance = try throwingFuncReturns() catch ... { </b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>/* handle error */ </b></div><div><b>}</b></div><div><br></div><div>This mechanism also makes the error handling more powerful, since it can catch more specific errors defined with '<b>where condition</b>'.</div><div><br></div><div>Lets rebuild the example from above with the new mechanism:</div><div><br></div><div><b>guard let listener = try TCPListener("some valid address") catch {</b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>fatalError()</b></div><div><b>}</b></div><div><b><br></b></div><div><b>guard let clientConn = try listener.accept() catch {</b></div><div><b><span class="Apple-tab-span" style="white-space:pre"> </span>fatalError()</b></div><div><b>} </b></div><div><br></div><div>One think that should be mentioned here is that the method call from the second '<b>guard</b>' is safe, because a '<b>guard</b>' body may not fall through.</div><div><br></div><div>Impact on existing codebase: <i><u>None</u></i>, because the mechanism is new and does not break any existing code.</div><div><br></div><div>I'm really curious about your opinions.</div></body></html>