Task.Result è uguale a .GetAwaiter.GetResult ()?

Recentemente stavo leggendo del codice che utilizza molti metodi asincroni, ma a volte ha bisogno di eseguirli in modo sincrono. Il codice fa:

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

È lo stesso di

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

Abbastanza. Una piccola differenza però: se il Taskfallimento fallisce, GetResult()genererà direttamente l'eccezione causata direttamente, mentre Task.Resultgenererà un AggregateException. Tuttavia, qual è lo scopo di utilizzare uno di quelli quando è async? L'opzione 100x migliore è da usare await.

Inoltre, non sei destinato a utilizzare GetResult(). È pensato solo per l'uso del compilatore, non per te. Ma se non vuoi il fastidioso AggregateException, usalo .

Task.GetAwaiter().GetResult()è preferito Task.Waite Task.Resultperché propaga le eccezioni piuttosto che racchiuderle in un file AggregateException. Tuttavia, tutti e tre i metodi causano il potenziale per deadlock e problemi di fame del pool di thread. Tutti dovrebbero essere evitati a favore di async/await.

La citazione seguente spiega perché Task.Waite Task.Resultnon contiene semplicemente il comportamento di propagazione delle eccezioni di Task.GetAwaiter().GetResult()(a causa di una "barra di compatibilità molto elevata").

Come accennato in precedenza, abbiamo una barra di compatibilità molto elevata e quindi abbiamo evitato di interrompere le modifiche. Come tale, Task.Waitmantiene il suo comportamento originale di sempre avvolgente. Tuttavia, potresti trovarti in alcune situazioni avanzate in cui desideri un comportamento simile al blocco sincrono impiegato Task.Wait, ma in cui desideri che l'eccezione originale venga propagata da scartare anziché essere racchiusa in un AggregateException. Per raggiungere questo obiettivo, puoi indirizzare direttamente il cameriere dell'attività. Quando scrivi “ await task;”, il compilatore lo traduce in uso del Task.GetAwaiter()metodo, che restituisce un'istanza che ha un GetResult()metodo. Se utilizzato su un'attività con errori, GetResult()propaga l'eccezione originale (in questo modo " await task;" ottiene il suo comportamento). Puoi quindi utilizzare "task.GetAwaiter().GetResult()"Se si desidera invocare direttamente questa logica di propagazione.

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

" GetResult" In realtà significa "controllare l'attività per errori"

In generale, faccio del mio meglio per evitare il blocco sincrono su un'attività asincrona. Tuttavia, ci sono alcune situazioni in cui viola tale linea guida. In quelle rare condizioni, il mio metodo preferito è GetAwaiter().GetResult()perché conserva le eccezioni dell'attività anziché racchiuderle in un file AggregateException.

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

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

"Un'ultima osservazione: dovresti evitare di usare Task.Resulte Task.Waitquanto più possibile incapsulano sempre l'eccezione interna in un AggregateExceptione sostituisci il messaggio con uno generico (si sono verificati uno o più errori), il che rende più difficile il debug. Anche se la versione sincrona non dovrebbe dovrebbe essere usato così spesso, dovresti prendere in seria considerazione di utilizzare Task.GetAwaiter().GetResult()invece ".

Un'altra differenza è quando la asyncfunzione ritorna proprio Taskinvece di Task<T>allora non è possibile utilizzare

GetFooAsync(...).Result;

Mentre

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

funziona ancora.

So che il codice di esempio nella domanda è per il caso Task<T>, tuttavia la domanda viene posta in generale.

Come già accennato se è possibile utilizzare await. Se hai bisogno di eseguire il codice in modo sincrono come dici tu .GetAwaiter().GetResult(), .Resulto .Wait()è un rischio per deadlock, come molti hanno detto nei commenti / risposte. Dal momento che molti di noi amano gli oneliner, puoi usarli per.Net 4.5<

Acquisizione di un valore tramite un metodo asincrono:

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

Chiamare in modo sincrono un metodo asincrono

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

Non si verificheranno problemi di deadlock dovuti all'uso di Task.Run.

Fonte:

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

Se un'attività fallisce, l'eccezione viene generata di nuovo quando il codice di continuazione chiama awaiter.GetResult (). Invece di chiamare GetResult, potremmo semplicemente accedere alla proprietà Result dell'attività. Il vantaggio di chiamare GetResult è che se l'attività fallisce, l'eccezione viene generata direttamente senza essere racchiusa in AggregateException, consentendo blocchi di cattura più semplici e più puliti.

Per attività non generiche, GetResult () ha un valore di ritorno vuoto. La sua utile funzione è quindi solo quella di riproporre le eccezioni.

fonte: c # 7.0 in breve