Qual é o objetivo do "retorno aguardar" em c #?

Existe algum cenário em que escrever método como este:

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

em vez disso:

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

faria sentido?

Por que usar return awaitconstruct quando você pode retornar diretamente Task<T>da DoAnotherThingAsync()invocação interna ?

Eu vejo código return awaitem muitos lugares, acho que posso ter perdido alguma coisa. Mas, tanto quanto eu entendo, não usar palavras-chave async / wait neste caso e retornar diretamente a tarefa seria funcionalmente equivalente. Por que adicionar sobrecarga adicional de awaitcamada adicional ?

Há um caso sorrateiro quando returnno método normal e return awaitno asyncmétodo se comporta de maneira diferente: quando combinado com using(ou, mais geralmente, return awaitem um trybloco).

Considere estas duas versões de um método:

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

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

O primeiro método fará Dispose()o Fooobjeto assim que o DoAnotherThingAsync()método retornar, o que provavelmente é muito antes de ele realmente ser concluído. Isso significa que a primeira versão provavelmente está com erros (porque Fooé descartada muito cedo), enquanto a segunda versão funcionará bem.

Se você não precisar async(por exemplo, você pode retornar o Taskdiretamente), não use async.

Há algumas situações em que return awaité útil, como se você tiver duas operações assíncronas para fazer:

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

Para asyncsaber mais sobre desempenho, consulte o artigo e o vídeo de Stephen Toub no MSDN sobre o tópico.

Atualização: escrevi uma postagem de blog que entra em muito mais detalhes.

O único motivo para você querer fazer isso é se houver algum outro awaitno código anterior ou se você estiver de alguma forma manipulando o resultado antes de devolvê-lo. Outra maneira pela qual isso pode estar acontecendo é através de uma try/catchalteração na maneira como as exceções são tratadas. Se você não está fazendo nada disso, está certo, não há razão para adicionar a sobrecarga de criar o método async.

Outro caso em que você pode precisar aguardar o resultado é este:

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

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

Nesse caso, GetIFooAsync()deve aguardar o resultado de, GetFooAsyncporque o tipo de Té diferente entre os dois métodos e Task<Foo>não é diretamente atribuível a Task<IFoo>. Mas se você aguardar o resultado, ele se tornará o Fooque é diretamente atribuível IFoo. Em seguida, o método assíncrono apenas reembala o resultado por dentro Task<IFoo>e por fora.

Tornar o método "thunk" simples de outra forma assíncrono cria uma máquina de estado assíncrona na memória, enquanto a não assíncrona não. Embora isso possa apontar as pessoas para o uso da versão não assíncrona porque é mais eficiente (o que é verdade), isso também significa que, no caso de um travamento, você não tem evidências de que esse método esteja envolvido na "pilha de retorno / continuação" o que às vezes torna mais difícil entender o jeito.

Então, sim, quando o perf não for crítico (e geralmente não é), lançarei o assíncrono em todos esses métodos de thunk, para que eu tenha a máquina de estado assíncrona para me ajudar a diagnosticar travamentos mais tarde e também para garantir que, se esses Se os métodos thunk evoluírem com o tempo, eles retornarão tarefas com falha em vez de jogar.

Se você não usar o retorno aguardar, poderá arruinar o rastreamento da pilha durante a depuração ou quando ele for impresso nos logs com exceções.

Quando você retorna a tarefa, o método cumpriu sua finalidade e está fora da pilha de chamadas. Quando você usareturn await você o deixa na pilha de chamadas.

Por exemplo:

Pilha de chamadas ao usar a espera: A aguardando a tarefa de B => B aguardando a tarefa de C

Pilha de chamadas quando não estiver usando aguardar: A aguardando a tarefa de C, que B retornou.

Isso também me confunde e sinto que as respostas anteriores ignoraram sua pergunta real:

Por que usar return wait aguardar construção quando você pode retornar diretamente Task da chamada interna DoAnotherThingAsync ()?

Bem, às vezes você realmente deseja um Task<SomeType>, mas na maioria das vezes deseja uma instância do SomeTyperesultado da tarefa.

Do seu código:

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

Uma pessoa não familiarizada com a sintaxe (eu, por exemplo) pode pensar que esse método deve retornar a Task<SomeResult>, mas como está marcado com async, significa que seu tipo de retorno real é SomeResult. Se você apenas usar return foo.DoAnotherThingAsync(), retornará uma tarefa que não será compilada. A maneira correta é retornar o resultado da tarefa, então o return await.