<div dir="ltr">I want to bump <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003284.html">the old thread</a> on &quot;typed throws&quot;.<div><br></div><div>First of all, I just love the improvement from the caller point of view. The following:</div><div><br></div><div>func updateData() throws DataUpdateError -&gt; Data</div><div><br></div><div>do {</div><div>    let updates = try updateData()</div><div>    doTheUpdate(updates)</div><div>} catch .DownloadError {</div><div>    //...</div><div>} catch .InvalidError {</div><div>    //...</div><div>}</div><div><br></div><div>Is much better than the following:</div><div><br></div><div>func updateData() throws -&gt; Data<br></div><div><br></div><div><div>do {</div><div>    let updates = try updateData()</div><div>    doTheUpdate(updates)</div><div>} catch DataUpdateError.DownloadError {</div><div>    //...</div><div>} catch DataUpdateError.InvalidError {</div><div>    //...</div><div>} catch {</div></div><div>    fatalError()</div><div>}</div><div><br></div><div>The main arguments for me are:</div><div>1. It is clear from the function definition, what errors will be thrown</div><div>2. The IDE also knows the error type and will help me as soon as I type the dot</div><div>3. No catch-all boilerplate</div><div><br></div><div>Many people don&#39;t seem to understand the difference between Swift errors and exceptions, that are like &quot;the current task has failed, period&quot;. Swift errors carry information that is enough to recover from the error close to the throwing call. If it cannot be immediately recovered from, it should be converted to appropriate kind of unchecked exception. That is why it is useful and logical for the calling side to be informed of the whole range of possible errors. In type-safe way, if possible.</div><div><br></div><div>Some developer teams already use this paradigm, although the language makes it more difficult currently. It just disciplines error handling.</div><div><br></div><div>The difficulties begin at the &quot;throwing side&quot;, where we have all these error conversion issues.</div><div><br></div><div>I suggest that regardless of whether we do or do not find a way to resolve those, we should add typed throws to the language. Developers of APIs that use errors and want to simplify life for their users, will be able to do so. If you don&#39;t want to mess with errors in your own code, continue to use untyped &#39;throws&#39;.</div><div><br></div><div>That&#39;s my main point. Additionally, I have a couple of (possibly dumb) suggestions for error conversion.</div><div><br></div><div>Assume we have &#39;ErrorTwo(errorConversion:ErrorOne)&#39; or other convention for declaring convertion possibility. Then we have the following situation:</div><div><br></div><div><div>func foo() throws ErrorOne</div><div>func test() throws ErrorTwo {</div><div>    // how to call foo() ?</div><div>}</div></div><div><br></div><div>0. Current way (do-catch):</div><div><br></div><div>do {</div><div>    try foo()</div><div>} catch err as ErrorOne {</div><div>    throw ErrorTwo(errorConvertion: err)</div><div>}</div><div><br></div><div>Verbose.</div><div><br></div><div>1. Implicit error conversions:</div><div><br></div><div>try foo()</div><div><br></div><div>IMO, they are not as bad as implicit convertions would be in other parts of the language. Just keep in mind that &#39;try&#39; might convert its error type to match &#39;throws&#39; type of the current function.</div><div><br></div><div>2. &#39;try as&#39;</div><div><br></div><div>try as ErrorTwo foo()<br></div><div><br></div><div>Uses existing keywords, but contains excessive information about the resulting error type. What if that type was long?</div><div><br></div><div><div>3. Add a keyword or attribute for &#39;try&#39; with conversion:</div></div><div><br></div><div>convertingtry foo()</div><div>converting try foo()</div><div>@converting try foo()</div><div><br></div><div>I prefer the attribute version.<br></div></div>