> On Feb 28, 2017, at 12:27 PM, Tino Heth via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> 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.
This is something I have discussed extensively in the thread titled “Analysis
of the design of typed throws”. I am interested if you have any comments on
that discussion.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
