Warten vs. Ergebnis: Wann sollten Sie „await' anstelle von „.Result' in C#-Async-Aufgaben verwenden?

Auswahl von await und .Result in asynchronen C#-Aufgaben

In Stephen Clearys „C# Concurrent Programming Handbook“ erregte eine Technik meine Aufmerksamkeit:

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

Da downloadTask ohne Timeout abgeschlossen worden wäre, warum müssen wir dann ein zweites await ausführen, anstatt direkt zu downloadTask.Result zurückzukehren?

Vorteile von

await gegenüber .Result

Der Autor hebt zwei Hauptgründe für die Verwendung von await gegenüber .Result (oder Wait) hervor:

1. Ausnahmebehandlung: await schließt Ausnahmen nicht in AggregateException ein und bietet so einen klareren Ausnahmebehandlungsmechanismus.
2. Deadlocks vermeiden: Die Verwendung von .Result oder Wait innerhalb einer asynchronen Methode kann zu Deadlocks oder subtilen Laufzeitproblemen führen.

Benutzerhandbuch

Obwohl die Verwendung von .Result oder Wait nicht vollständig verboten ist, werden die folgenden Richtlinien empfohlen:

• Asynchroner Anwendungscode: Verwenden Sie immer await.
• Asynchronous Utility Library: Kann mit .Result oder Wait mit Vorsicht und ausreichender Dokumentation verwendet werden.
• Parallel-Task-Code: Für nicht-asynchrone parallele Tasks sind .Result und Wait geeignet.

Durch die Befolgung dieser Richtlinien können Entwickler die Ausnahmebehandlung verbessern, Deadlocks verhindern und robusteren und wartbareren asynchronen Code schreiben.

Das obige ist der detaillierte Inhalt vonWarten vs. Ergebnis: Wann sollten Sie „await' anstelle von „.Result' in C#-Async-Aufgaben verwenden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!