[swift-evolution] [Pitch] Typed throws
Adrian Zubarev
adrian.zubarev at devandartist.com
Fri Feb 17 13:42:26 CST 2017
So the typed throws are going to be limited to a single error type, is that the direction we're heading to?
--
Adrian Zubarev
Sent with Airmail
Am 17. Februar 2017 um 20:39:12, Anton Zhilin (antonyzhilin at gmail.com) schrieb:
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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/d88aa74b/attachment.html>
More information about the swift-evolution
mailing list