In this case, you’d better create a new error type, which includes all the
cases of those errors:
// FileNotFoundError and WrongFormat are Error-s
struct PreferencesError : Error {
init(_: FileNotFoundError)
init(_: WrongFormat)
// ...
}
func readPreferences() throws(PreferencesError)
In the most “lazy” case, you’d just create an enum of those two:
enum PreferencesError : Error {
case fileNotFound(FileNotFoundError)
case wrongFormat(WrongFormatError)
}
Better yet, you should analyze, which cases are meaningful for user of
readPreferences, and present them with appropriate interface. You may want
to crash on those cases of initial error types, with which you can’t do
anything on the level of abstraction of readPreferences. Some of the others
will be merged or renamed.
With proper error types, a single type in throws clause is enough, without
sum types.
2017-02-17 22:22 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:
Sure thing, but that’s not what I was asking about. Kevin made a protocol
> that conforms to Error where all the his enums conformed to MyError
> protocol. That way we’re losing all enum cases and are not really a step
> further as before.
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
