Task.Result é o mesmo que .GetAwaiter.GetResult ()?

Recentemente, eu estava lendo algum código que usa muitos métodos assíncronos, mas às vezes precisa executá-los de forma síncrona. O código faz:

Foo foo = GetFooAsync(...).GetAwaiter().GetResult();

É o mesmo que

Foo foo = GetFooAsync(...).Result;

Bastante. Porém, uma pequena diferença: se Taskfalhar, GetResult()lançará apenas a exceção causada diretamente, enquanto Task.Resultlançará um AggregateException. No entanto, qual é o sentido de usar um desses quando é async? A opção 100x melhor é usar await.

Além disso, você não deve usar GetResult(). É para ser apenas para uso do compilador, não para você. Mas se você não quer o irritante AggregateException, use-o.

Task.GetAwaiter().GetResult()é preferido Task.Waite Task.Resultporque propaga exceções em vez de agrupá-las em um arquivo AggregateException. No entanto, todos os três métodos causam o potencial de problemas de falta de deadlock e pool de encadeamentos. Todos eles devem ser evitados em favor de async/await.

A citação abaixo explica por que Task.Waite Task.Resultnão contém simplesmente o comportamento de propagação de exceção de Task.GetAwaiter().GetResult()(devido a uma "barra de compatibilidade muito alta").

Como mencionei anteriormente, temos uma barra de compatibilidade muito alta e, portanto, evitamos interromper as alterações. Como tal, Task.Waitmantém seu comportamento original de sempre quebrar. No entanto, você pode se encontrar em algumas situações avançadas em que deseja um comportamento semelhante ao bloqueio síncrono empregado por Task.Wait, mas em que deseja que a exceção original seja propagada sem quebra, em vez de envolvida em um AggregateException. Para conseguir isso, você pode direcionar o garçom da tarefa diretamente. Quando você escreve “ await task;”, o compilador converte isso no uso do Task.GetAwaiter()método, que retorna uma instância que possui um GetResult()método. Quando usado em uma tarefa com falha, GetResult()propagará a exceção original (é assim que " await task;" obtém seu comportamento). Você pode usar "task.GetAwaiter().GetResult()”Se você desejar chamar diretamente essa lógica de propagação.

https://blogs.msdn.microsoft.com/pfxteam/2011/09/28/task-exception-handling-in-net-4-5/

" GetResult" Significa realmente "verifique a tarefa quanto a erros"

Em geral, tento o meu melhor para evitar o bloqueio síncrono de uma tarefa assíncrona. No entanto, existem algumas situações em que eu viole essa diretriz. Nessas condições raras, meu método preferido é GetAwaiter().GetResult()porque preserva as exceções da tarefa em vez de agrupá-las em um AggregateException.

http://blog.stephencleary.com/2014/12/a-tour-of-task-part-6-results.html

https://github.com/aspnet/Security/issues/59

"Uma última observação: você deve evitar usar Task.Resulte Task.Wait, tanto quanto possível, como sempre encapsular a exceção interna em uma AggregateExceptione substituir a mensagem por um genérico (um ou mais erros), o que torna a depuração mais difícil Mesmo que a versão shouldn síncrona. não seja usado com tanta frequência, você deve considerar fortemente o uso Task.GetAwaiter().GetResult()".

Outra diferença é quando a asyncfunção retorna apenas em Taskvez de Task<T>então você não pode usar

GetFooAsync(...).Result;

Enquanto que

GetFooAsync(...).GetAwaiter().GetResult();

ainda funciona.

Eu sei que o código de exemplo na pergunta é para o caso Task<T>, no entanto, a pergunta é feita geralmente.

Como já mencionado, se você pode usar await. Se você precisar executar o código de forma síncrona como você mencionou .GetAwaiter().GetResult(), .Resultou.Wait() houver um risco de conflito, como muitos disseram em comentários / respostas. Como a maioria de nós gosta de oneliners, você pode usá-los para.Net 4.5<

Adquirindo um valor por meio de um método assíncrono:

var result = Task.Run(() => asyncGetValue()).Result;

Chamando de forma síncrona um método assíncrono

Task.Run(() => asyncMethod()).Wait();

Nenhum problema de conflito ocorrerá devido ao uso de Task.Run.

Fonte:

https://stackoverflow.com/a/32429753/3850405

Se uma tarefa falhar, a exceção será lançada novamente quando o código de continuação chamar waititer.GetResult (). Em vez de chamar GetResult, poderíamos simplesmente acessar a propriedade Result da tarefa. O benefício de chamar GetResult é que, se a tarefa falhar, a exceção será lançada diretamente sem ser agrupada em AggregateException, permitindo blocos de captura mais simples e limpos.

Para tarefas não genéricas, GetResult () possui um valor de retorno nulo. Sua função útil é, então, apenas relançar exceções.

fonte: c # 7.0 em poucas palavras