<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I'm hopping in here ridiculously late, but wasn't someone going to propose a vanilla universal stdlib error type along the lines of</div><div class=""><br class=""></div><div class="">struct Error: ErrorType {</div><div class="">&nbsp; &nbsp;let reason: String</div><div class="">}</div><div class=""><br class=""></div><div class="">(preferably with auto-captured location context (<a href="http://ericasadun.com/2015/08/27/capturing-context-swiftlang/" class="">http://ericasadun.com/2015/08/27/capturing-context-swiftlang/</a>) and a custom mutable dictionary.)</div><div class=""><br class=""></div><div class="">-- Erica</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 5, 2016, at 5:59 PM, Brent Royal-Gordon via swift-users &lt;<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">"so pretty much every non-trivial #swift function should throw, right? &nbsp;cheap &amp; gives caller choice to catch, rethrow, try? or try! &nbsp;(4 in 1)"<br class="">-- <a href="https://twitter.com/johnspurlock/status/704478619779866625" class="">https://twitter.com/johnspurlock/status/704478619779866625</a><br class=""><br class="">[snip]<br class=""><br class="">Given that Swift provides multiple language-standard ways for clients to deal with a function marked as 'throws', it seems like almost all non-trivial shared functions should provide the additional information of the error in that standard form, instead of hiding it behind an optional return type<br class=""></blockquote><br class="">No, I don't think so.<br class=""><br class="">First of all, there are functions which I can't imagine describing as trivial, but which nonetheless cannot fail except by programmer error. For instance, sorting can only fail if you provide a comparator which doesn't work properly (by, for instance, saying that both `a &lt; b` and `b &lt; a` are true). There is no error reporting needed at all for sorting, because the only possible errors are outright mistakes by the programmer. Those should be handled with preconditions, and the function itself should not signal the possibility of an error in any way at all.<br class=""><br class=""></div></div></blockquote><br class=""></div><div>... etc</div><div><br class=""></div><div><br class=""></div><br class=""></body></html>