Quel est le but du «retour en attente» en C #?

Y a-t-il un scénario où une méthode d'écriture 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 du sens?

Pourquoi utiliser la return awaitconstruction alors que vous pouvez directement revenir Task<T>de l' DoAnotherThingAsync()invocation intérieure ?

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

Il y a un cas sournois quand returndans la méthode normale et return awaitdans la asyncméthode se comportent différemment: lorsqu'ils sont combinés avec using(ou, plus généralement, tout return awaitdans un trybloc).

Considérez 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 sera Dispose()l' Fooobjet dès le DoAnotherThingAsync()retour de la méthode, ce qui est probablement bien avant qu'elle ne se termine réellement. Cela signifie que la première version est probablement boguée (car Foosupprimée trop tôt), tandis que la deuxième version fonctionnera correctement.

Si vous n'en avez pas besoin async(c.-à-d., Vous pouvez retourner le Taskdirectement), alors ne l'utilisez pas async.

Il y a certaines situations où cela return awaitest utile, comme si vous avez deux opérations asynchrones à faire:

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

Pour plus d'informations sur les asyncperformances, consultez l' article et la vidéo MSDN de Stephen Toub sur le sujet.

Mise à jour: j'ai écrit un article de blog qui va beaucoup plus en détail.

La seule raison pour laquelle vous voudriez le faire est s'il y en a un autre awaitdans le code précédent, ou si vous manipulez le résultat d'une manière ou d'une autre avant de le retourner. Une autre façon dont cela pourrait se produire est de try/catchmodifier la façon dont les exceptions sont gérées. Si vous ne faites rien de tout cela, vous avez raison, il n'y a aucune raison d'ajouter la surcharge de la méthode async.

Un autre cas dont vous devrez peut-être attendre le résultat est celui-ci:

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

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

Dans ce cas, GetIFooAsync()doit attendre le résultat GetFooAsynccar le type de Test 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 ce Fooqui est directement attribuable à IFoo. Ensuite, la méthode async reconditionne simplement le résultat à l'intérieur Task<IFoo>et à l'extérieur.

Rendre la méthode "thunk" autrement simple asynchrone crée une machine d'état asynchrone en mémoire alors que celle non-async ne le fait pas. Bien que cela puisse souvent inciter les gens à utiliser la version non asynchrone car elle est plus efficace (ce qui est vrai), cela signifie également qu'en cas de blocage, vous n'avez aucune preuve que cette méthode est impliquée dans la "pile de retour / continuation". ce qui rend parfois plus difficile la compréhension du blocage.

Alors oui, lorsque la perf n'est pas critique (et ce n'est généralement pas le cas), je lancerai asynchrone sur toutes ces méthodes de thunk afin d'avoir la machine d'état asynchrone pour m'aider à diagnostiquer les blocages plus tard, et aussi pour m'assurer que si ces les méthodes de thunk évoluent au fil du temps, elles seront sûres de retourner les tâches en défaut au lieu de lancer.

Si vous n'utilisez pas return wait, vous pouvez ruiner la trace de votre pile pendant le débogage ou lorsqu'elle est imprimée dans les journaux des exceptions.

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

Par exemple:

Pile d'appels lors de l'utilisation de l'attente: A en attente de la tâche de B => B en attente de la tâche de C

Pile d'appels lorsque vous n'utilisez pas wait: A attend la tâche de C, que B a renvoyée.

Cela m'embrouille également et je pense que les réponses précédentes ont ignoré votre question réelle:

Pourquoi utiliser la construction return wait alors que vous pouvez directement renvoyer Task à partir de l'invocation intérieure DoAnotherThingAsync ()?

Eh bien, parfois, vous voulez vraiment un Task<SomeType>, mais la plupart du temps, vous voulez en fait une instance SomeType, c'est-à-dire le résultat de la tâche.

Depuis votre code:

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

Une personne qui ne connaît pas la syntaxe (moi, par exemple) pourrait penser que cette méthode devrait retourner un Task<SomeResult>, mais comme elle est marquée avec async, cela signifie que son type de retour réel est SomeResult. Si vous utilisez simplement return foo.DoAnotherThingAsync(), vous retourneriez une tâche qui ne serait pas compilée. La bonne façon est de renvoyer le résultat de la tâche, donc le return await.