Task.Result est-il le même que .GetAwaiter.GetResult ()?

Je lisais récemment du code qui utilise beaucoup de méthodes asynchrones, mais a parfois besoin de les exécuter de manière synchrone. Le code:

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

Est-ce la même chose que

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

Plutôt. Une petite différence cependant: si l' Taskéchec, GetResult()lance simplement l'exception provoquée directement, tandis que Task.Resultlance un AggregateException. Cependant, quel est l'intérêt d'utiliser l'un ou l'autre de ceux-ci quand c'est async? L'option 100x meilleure est d'utiliser await.

De plus, vous n'êtes pas censé l'utiliser GetResult(). Il est destiné à être utilisé uniquement par le compilateur, pas pour vous. Mais si vous ne voulez pas être ennuyeux AggregateException, utilisez-le.

Task.GetAwaiter().GetResult()est préféré Task.Waitet Task.Resultparce qu'il propage des exceptions plutôt que de les encapsuler dans un AggregateException. Cependant, les trois méthodes peuvent entraîner des problèmes de blocage et de famine du pool de threads. Ils devraient tous être évités en faveur de async/await.

La citation ci-dessous explique pourquoi Task.Waitet Task.Resultne contient pas simplement le comportement de propagation d'exception de Task.GetAwaiter().GetResult()(en raison d'une "barre de compatibilité très élevée").

Comme je l'ai mentionné précédemment, nous avons une barre de compatibilité très élevée, et nous avons donc évité de casser les changements. En tant que tel, Task.Waitconserve son comportement d'origine de toujours envelopper. Cependant, vous pouvez vous retrouver dans certaines situations avancées où vous souhaitez un comportement similaire au blocage synchrone utilisé par Task.Wait, mais où vous souhaitez que l'exception d'origine se propage sans être enveloppée plutôt qu'elle ne soit enfermée dans un AggregateException. Pour y parvenir, vous pouvez cibler directement l'attente de la tâche. Lorsque vous écrivez « await task;», le compilateur traduit cela en utilisation de la Task.GetAwaiter()méthode, qui renvoie une instance qui a une GetResult()méthode. Lorsqu'il est utilisé sur une tâche défaillante, GetResult()propage l'exception d'origine (c'est ainsi que « await task;» obtient son comportement). Vous pouvez donc utiliser "task.GetAwaiter().GetResult()»Si vous souhaitez appeler directement cette logique de propagation.

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

" GetResult" Signifie en fait "vérifier la tâche pour les erreurs"

En général, je fais de mon mieux pour éviter le blocage synchrone sur une tâche asynchrone. Cependant, il y a une poignée de situations où je viole cette directive. Dans ces rares conditions, ma méthode préférée est GetAwaiter().GetResult()parce qu'elle préserve les exceptions de tâche au lieu de les envelopper dans un AggregateException.

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

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

« Une dernière remarque: vous devriez éviter d' utiliser Task.Resultet Task.Waitautant que possible car ils encapsuler toujours l'exception interne dans un AggregateExceptionet remplacer le message par un générique (un ou plusieurs se sont produites des erreurs), ce qui rend le débogage plus difficile même si la version synchrone shouldn. ne pas être utilisé aussi souvent, vous devriez sérieusement envisager de l'utiliser à la Task.GetAwaiter().GetResult()place. "

Une autre différence est que lorsque la asyncfonction retourne juste Taskau lieu de, Task<T>vous ne pouvez pas utiliser

GetFooAsync(...).Result;

Tandis que

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

fonctionne encore.

Je sais que l'exemple de code dans la question est pour le cas Task<T>, mais la question est généralement posée.

Comme déjà mentionné si vous pouvez utiliser await. Si vous devez exécuter le code de manière synchrone comme vous le mentionnez .GetAwaiter().GetResult(), .Resultou si vous .Wait()risquez de bloquer, comme beaucoup l'ont dit dans les commentaires / réponses. Comme la plupart d'entre nous aiment les oneliners, vous pouvez les utiliser pour.Net 4.5<

Acquisition d'une valeur via une méthode asynchrone:

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

Appel synchrone d'une méthode asynchrone

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

Aucun problème de blocage ne se produira en raison de l'utilisation de Task.Run.

La source:

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

Si une tâche échoue, l'exception est renvoyée lorsque le code de continuation appelle waiter.GetResult (). Plutôt que d'appeler GetResult, nous pourrions simplement accéder à la propriété Result de la tâche. L'avantage d'appeler GetResult est que si la tâche échoue, l'exception est levée directement sans être encapsulée dans AggregateException, ce qui permet des blocs de capture plus simples et plus propres.

Pour les tâches non génériques, GetResult () a une valeur de retour vide. Sa fonction utile est alors uniquement de renvoyer les exceptions.

source: c # 7.0 en bref