Pourquoi utiliser async et renvoyer await, alors que vous pouvez renvoyer directement Task<T> ?

Question

Y a-t-il tous scénario où l'on écrit une méthode comme celle-ci :

public async Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return await DoAnotherThingAsync();
}

au lieu de cela :

public Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return DoAnotherThingAsync();
}

aurait-elle un sens ?

Pourquoi utiliser return await alors que vous pouvez directement renvoyer Task<T> de l'intérieur DoAnotherThingAsync() invocation ?

Je vois un code avec return await dans tant d'endroits, je pense que j'ai peut-être raté quelque chose. Mais pour autant que je comprenne, ne pas utiliser les mots-clés async/await dans ce cas et renvoyer directement la tâche serait fonctionnellement équivalent. Pourquoi ajouter des frais généraux supplémentaires de await couche ?

Answer 1

Il y a un cas sournois où return en méthode normale et return await en async se comporte différemment : lorsqu'elle est combinée avec la méthode using (ou, plus généralement, tout return await dans un try bloc).

Considérons ces deux versions d'une méthode :

Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return foo.DoAnotherThingAsync();
    }
}

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

La première méthode Dispose() les Foo dès que l'objet DoAnotherThingAsync() ce qui est probablement le cas bien avant qu'elle ne soit terminée. Cela signifie que la première version est probablement boguée (parce que Foo est éliminé trop tôt), tandis que la seconde version fonctionnera parfaitement.

Answer 2

Si vous n'avez pas besoin de async (c'est-à-dire que vous pouvez renvoyer l'élément Task directement), alors n'utilisez pas async .

Il existe des situations où return await est utile, comme si vous aviez deux les opérations asynchrones à effectuer :

var intermediate = await FirstAsync();
return await SecondAwait(intermediate);

Pour en savoir plus async performance, voir l'article de Stephen Toub Article de MSDN y vidéo sur le sujet.

Mise à jour : J'ai écrit un article de blog qui donne beaucoup plus de détails.

Answer 3

La seule raison pour laquelle vous voudriez le faire est qu'il existe une autre await dans le code précédent, ou si vous manipulez d'une manière ou d'une autre le résultat avant de le renvoyer. Cela peut également se produire par le biais d'une fonction try/catch qui modifie la façon dont les exceptions sont gérées. Si vous ne faites rien de tout cela, alors vous avez raison, il n'y a pas de raison d'ajouter la surcharge de rendre la méthode async .

Answer 4

Si vous n'utilisez pas le retour attendu, vous risquez de gâcher votre trace de pile lors du débogage ou lorsqu'elle est imprimée dans les journaux en cas d'exception.

Lorsque vous renvoyez la tâche, la méthode a rempli son objectif et est sortie de la pile d'appels. Lorsque vous utilisez return await vous le laissez dans la pile d'appels.

Par exemple :

Appeler la pile lors de l'utilisation de await : A attend la tâche de B => B attend la tâche de C

Appeler la pile lorsque no en utilisant await : A attend la tâche de C, que B a renvoyée.

Answer 5

Voici un autre cas où vous devrez peut-être attendre le résultat :

async Task<IFoo> GetIFooAsync()
{
    return await GetFooAsync();
}

async Task<Foo> GetFooAsync()
{
    var foo = await CreateFooAsync();
    await foo.InitializeAsync();
    return foo;
}

En l'occurrence, GetIFooAsync() doit attendre le résultat de GetFooAsync car le type de T est différent entre les deux méthodes et Task<Foo> n'est pas directement attribuable à Task<IFoo> . Mais si vous attendez le résultat, il devient tout simplement Foo qui est directement attribuables à IFoo . La méthode asynchrone se contente alors de reconditionner le résultat à l'intérieur de Task<IFoo> et c'est parti.