[swift-users] Every non-trivial Swift function should throw, right?
Erica Sadun
erica at ericasadun.com
Sat Mar 5 20:58:33 CST 2016
I'm hopping in here ridiculously late, but wasn't someone going to propose a vanilla universal stdlib error type along the lines of
struct Error: ErrorType {
let reason: String
}
(preferably with auto-captured location context (http://ericasadun.com/2015/08/27/capturing-context-swiftlang/ <http://ericasadun.com/2015/08/27/capturing-context-swiftlang/>) and a custom mutable dictionary.)
-- Erica
> On Mar 5, 2016, at 5:59 PM, Brent Royal-Gordon via swift-users <swift-users at swift.org> wrote:
>
>> "so pretty much every non-trivial #swift function should throw, right? cheap & gives caller choice to catch, rethrow, try? or try! (4 in 1)"
>> -- https://twitter.com/johnspurlock/status/704478619779866625
>>
>> [snip]
>>
>> 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
>
> No, I don't think so.
>
> 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 < b` and `b < 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.
>
... etc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160305/3af66ac1/attachment.html>
More information about the swift-users
mailing list