This proposal should be reviewed as a part of “typed throws” proposal, with the original PR <https://github.com/apple/swift-evolution/pull/68> prepared by David Owens.
Typed throws won’t change anything about how many types can be thrown. Only one type/protocol will be specified in the function type. You will still be able to specify throws Error by default, but in the cases, where API authors put some effort in their error handling, these APIs will be self-documented and undoubtably easier to work with. In many cases, one can at least specify some existential error type, which will be domain-specific, and still better than what we have now. I feel like Swift, together with Rust, can change current overall mess in error handling across many programming languages by providing not only syntax, but also semantics and guidelines. Swift errors, unlike exceptions, require dealing with them immediately. If one cannot deal with the error, but error details can be useful on hier levels of abstraction (for actually solving the problem, not logging), he still should put some work into wrapping the error, leaving only important details and preparing them for most conventient access. On syntax, I feel like this is the obvious one: func convert(_: String) -> Int throws IntegerConversionError Basically, we say that the function can either return an Int, or throw an IntegerConversionError. (Side note: yes, not NumericConversionError, if we want the API to both provide most detailed information when we need it, and express the range of possible errors for a particular function through the type system. However, one can also create hierarchies of error protocols to aid in abstraction—both abstraction and preciseness are important.) But can we make a step even further? One can say that the function returns “either Int or an error”. Rust users blame Swift for creating syntax sugar for everything—maybe we can live without it this time? Look at it this way: we already have a deep support for Optional<T> in the language. It’s so seamless, many people don’t even *realize* they work with Optional<T>. Can we make working with a standard enum Result<T, E> this simple? We can even leave current syntax in place, just T throws E will be a sugar for Result<T, E>. Methods of error handling described in this manifesto <https://github.com/apple/swift/blob/master/docs/ErrorHandling.rst> will be represented, respectively, by Optional, Result, and fatalError, with all of them defined in the standard library—isn’t that reasonable?
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
