Wann sollten Sie „await' anstelle von „Task.Result' für abgeschlossene Aufgaben verwenden?

await vs. Task.Result für abgeschlossene Aufgaben: Best Practices

Das „Concurrency in C# Cookbook“ zeigt ein Muster für die Handhabung abgeschlossener Aufgaben:

<code class="language-csharp">var completedTask = await Task.WhenAny(downloadTask, timeoutTask);
if (completedTask == timeoutTask)
  return null;
return await downloadTask;</code>

Dieser Code verwendet Task.WhenAny, um zu bestimmen, ob downloadTask (ein httpclient.GetStringAsync-Aufruf) vor timeoutTask (einem Task.Delay-Vorgang) abgeschlossen wird.

Warum await downloadTask verwenden, anstatt einfach downloadTask.Result zurückzugeben? Die Gründe sind entscheidend:

Ausnahmebehandlung:

• await vermeidet die Komplexität von AggregateException. Task.Result oder Task.Wait() schließen Ausnahmen in AggregateException ein und verschleiern so die Grundursache. Asynchroner Code sollte Ausnahmen idealerweise direkt behandeln, was await zur saubereren Lösung macht.

Deadlock-Vermeidung:

• Die Verwendung von Task.Result oder Task.Wait() innerhalb einer asynchronen Methode kann zu Deadlocks führen. await ist für asynchrone Kontexte konzipiert und verhindert diese häufige Gefahr.

Best Practices-Zusammenfassung:

• Bevorzugen await asynchronen Anwendungscode für eine bessere Ausnahmebehandlung und Deadlock-Verhinderung.
• Während Task.Result oder Task.Wait() im Dienstprogrammcode akzeptabel sein könnten (mit klaren Kommentaren, die die Gründe erläutern), werden sie im Allgemeinen am besten vermieden.
• Task.Result und Task.Wait() können für parallele Aufgabenszenarien in Betracht gezogen werden, in denen synchrones Blockieren akzeptabel und verständlich ist.

Das obige ist der detaillierte Inhalt vonWann sollten Sie „await' anstelle von „Task.Result' für abgeschlossene Aufgaben verwenden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!