¿Task.Result es lo mismo que .GetAwaiter.GetResult ()?

Recientemente estuve leyendo un código que usa muchos métodos asíncronos, pero que a veces necesita ejecutarlos sincrónicamente. El código hace:

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

¿Es esto lo mismo que

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

Más o menos. Sin embargo, una pequeña diferencia: si Taskfalla, GetResult()solo arrojará la excepción causada directamente, mientras Task.Resultque arrojará un AggregateException. Sin embargo, ¿cuál es el punto de usar cualquiera de esos cuando es async? La opción 100x mejor es usar await.

Además, no estás destinado a usar GetResult(). Está destinado a ser solo para uso del compilador, no para ti. Pero si no quieres lo molesto AggregateException, úsalo .

Task.GetAwaiter().GetResult()se prefiere sobre Task.Waity Task.Resultporque propaga excepciones en lugar de envolverlas en un AggregateException. Sin embargo, los tres métodos causan la posibilidad de problemas de inmovilización y de grupo de subprocesos. Todos deben ser evitados a favor de async/await.

La cita a continuación explica por qué Task.Waity Task.Resultno simplemente contiene el comportamiento de propagación de excepción de Task.GetAwaiter().GetResult()(debido a una "barra de compatibilidad muy alta").

Como mencioné anteriormente, tenemos una barra de compatibilidad muy alta y, por lo tanto, hemos evitado los cambios importantes. Como tal, Task.Waitconserva su comportamiento original de siempre envolver. Sin embargo, es posible que se encuentre en algunas situaciones avanzadas en las que desee un comportamiento similar al bloqueo sincrónico empleado Task.Wait, pero donde desee que la excepción original se propague sin envolver en lugar de encerrarse en un AggregateException. Para lograr eso, puede apuntar directamente al camarero de la Tarea. Cuando escribe " await task;", el compilador lo traduce al uso del Task.GetAwaiter()método, que devuelve una instancia que tiene un GetResult()método. Cuando se usa en una Tarea defectuosa, GetResult()propagará la excepción original (así es como " await task;" obtiene su comportamiento). Por lo tanto, puede usar "task.GetAwaiter().GetResult()"Si desea invocar directamente esta lógica de propagación.

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

" GetResult" En realidad significa "verificar la tarea en busca de errores"

En general, hago todo lo posible para evitar el bloqueo sincrónico en una tarea asincrónica. Sin embargo, hay un puñado de situaciones en las que sí viole esa directriz. En esas raras condiciones, mi método preferido es GetAwaiter().GetResult()porque conserva las excepciones de la tarea en lugar de envolverlas en un AggregateException.

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

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

"Una última observación: debe evitar el uso Task.Resulty en la Task.Waitmedida de lo posible, ya que siempre encapsulan la excepción interna en AggregateExceptiony reemplazan el mensaje por uno genérico (se produjeron uno o más errores), lo que dificulta la depuración. Incluso si la versión síncrona debería Si se usa con tanta frecuencia, debería considerar usarlo en su Task.GetAwaiter().GetResult()lugar ".

Otra diferencia es cuando la asyncfunción regresa en Tasklugar de Task<T>no poder usar

GetFooAsync(...).Result;

Mientras

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

todavía funciona.

Sé que el código de ejemplo en la pregunta es para el caso Task<T>, sin embargo, la pregunta se hace generalmente.

Como ya se mencionó si puede usar await. Si necesita ejecutar el código sincrónicamente como lo menciona .GetAwaiter().GetResult(), .Resulto si .Wait()existe un riesgo de puntos muertos, como muchos han dicho en los comentarios / respuestas. Como a la mayoría de nosotros nos gustan las líneas, puede usarlas para.Net 4.5<

Adquisición de un valor a través de un método asíncrono:

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

Llamar sincrónicamente a un método asíncrono

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

No se producirán problemas de punto muerto debido al uso de Task.Run.

Fuente:

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

Si falla una tarea, la excepción se vuelve a generar cuando el código de continuación llama a waititer.GetResult (). En lugar de llamar a GetResult, simplemente podríamos acceder a la propiedad Result de la tarea. El beneficio de llamar a GetResult es que si la tarea falla, la excepción se genera directamente sin estar envuelta en AggregateException, lo que permite bloques de captura más simples y limpios.

Para tareas no genéricas, GetResult () tiene un valor de retorno nulo. Su función útil es únicamente volver a lanzar excepciones.

fuente: c # 7.0 en una cáscara de nuez