> I disagree with that, it works if you only have a single function parameter
> type that throws an error, but if there are more than one inferring the type
> won’t be possible anymore: func foo(_: () throws(T) -> Void, _: () throws(S)
> -> Void) rethrows(S) (here, we’re assuming that T is handled inside foo).
>
Well, isn't it actually incorrect that "rethrows" is a property of the
function, and not of its parameters?
Just imagine this
func catches(catchMe: () throws -> Void, throwMe: () throws -> Void) rethrows {
try? catchMe()
try throwMe()
print("Nothing thrown")
}
func doesThrow() throws {
throw NSError()
}
func doesntThrow() {
print("I'm a nice function")
}
try catches(catchMe: doesThrow, throwMe: doesntThrow)
The last call can't throw, but the compiler still needs the "try" on it.
I guess in real-world code, this isn't an issue — but still, it's wrong… so if
we want a really sophisticated model for error handling, imho this should be
addressed.
Maybe we should also take into account that a higher-order function might catch
some errors, and only rethrow for special cases, and this adds complexity as
well?
In this case, each function-parameter would require a full list a errors that
are filtered out, or even a translation-table… I guess most developers would
agree that this is overkill, and that keeping things simple has merit as well._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
