[swift-evolution] [Question] Why does `beginAsync` rethrow errors?

Adam Kemp adam.kemp at apple.com
Tue Nov 7 22:28:40 CST 2017


I think I agree with this. beginAsync is similar to C#’s async void functions, and one of the gotchas in C# is that it is never safe to allow an exception to be thrown from an async void function. The reason is that if the exception happens after the continuation then there won’t be any application code above it to catch that exception. As a result, the built in behavior is to immediately crash the app.

This is unavoidable in C# where it’s impossible to write a function that is guaranteed not to throw. The semantics of exception throwing don’t allow for that in C#.

Swift has the advantage in this case of being able to statically verify that a function doesn’t throw so we can do better.

So I would argue in favor of not allowing beginAsync to throw at all.

FWIW, I also still think it would be better if we allowed for async void functions instead of requiring beginAsync in the first place. If I had my way then we would have async void, but an async void would not be allowed to throw.

> On Nov 7, 2017, at 7:04 PM, Yuta Koshizawa via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Although I posted about this topic before, let me post this again
> because I think it is important and I have received just few replies.
> Sorry if I missed some discussion about it.
> 
> In the proposal (
> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 ),
> `beginAsync` has the following signature.
> 
> ```
> func beginAsync(_ body: () async throws -> Void) rethrows -> Void
> ```
> 
> However, I think it is better to forbid `body` to throw errors, that
> is to say, to change its signature to the following one.
> 
> ```
> func beginAsync(_ body: () async -> Void) -> Void
> ```
> 
> Even if `beginAsync` allows that `body` throws errors, it can rethrow
> ones which are thrown before only first `await` call. In following
> cases, `beginAsync` just has to make the program crash when `foo`
> throws an error. It breaks safety for error handing by typed
> propagation realized by `throws/try`.
> 
> ```
> // throws errors asynchronously
> func foo() async throws -> Int { ... }
> 
> do {
>    beginAsync {
>        let a = try await foo()
>        // uses `a` here
>    }
> } catch _ {
>    // never reaches here
> }
> ```
> 
> If `beginAsync` forbid `body` to throw errors, it can be detected as a
> compilation error and is possible to fix it as follows.
> 
> ```
> beginAsync {
>    do {
>        let a = try await foo()
>        // uses `a` here
>    } catch _ {
>        //  error handling
>    }
> }
> ```
> 
> And even when we want to write `try` calls in `beginAsync` before
> first `await` call, those lines can be moved before the `beginAsync`
> call.
> 
> ```
> // before ( `beginAsync` marked with `rethrows` )
> do {
>    beginAsync {
>        let a = try bar()
>        let b = try baz()
>        let c = await qux(a, b)
>        // uses `c` here
>    }
> catch _ {
>    // error handling
> }
> 
> // after ( `beginAsync` without `rethrows` )
> do {
>    let a = try bar()
>    let b = try baz()
>    beginAsync {
>        let c = await qux(a, b)
>        // uses `c` here
>    }
> catch _ {
>    // error handling
> }
> ```
> 
> So the functionalities of `beginAsync` seems be kept even if it forbid
> `body` to throw errors.
> 
> What do you think about it?
> 
> --
> Yuta
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


More information about the swift-evolution mailing list