Attendre ou résultat : quand devez-vous utiliser « attendre » au lieu de « .Result » dans les tâches asynchrones C# ?

Choix de await et .Result dans les tâches asynchrones C#

Dans le "C# Concurrent Programming Handbook" de Stephen Cleary, une technique a retenu mon attention :

var completedTask = await Task.WhenAny(downloadTask, timeoutTask);
if (completedTask == timeoutTask)
  return null;
return await downloadTask;

Puisque downloadTask aurait été terminé sans délai d'attente, pourquoi devons-nous faire un deuxième await au lieu de revenir directement à downloadTask.Result ?

Avantages de

await par rapport à .Result

L'auteur met en évidence deux raisons principales pour utiliser await de préférence à .Result (ou Wait) :

1. Gestion des exceptions : await n'encapsule pas les exceptions dans AggregateException, offrant un mécanisme de gestion des exceptions plus clair.
2. Éviter les blocages : l'utilisation de .Result ou Wait dans une méthode asynchrone peut provoquer des blocages ou des problèmes d'exécution subtils.

Guide de l'utilisateur

Bien que l'utilisation de .Result ou Wait ne soit pas totalement interdite, les directives suivantes sont recommandées :

• Code d'application asynchrone : utilisez toujours await.
• Bibliothèque d'utilitaires asynchrones : peut être utilisée avec .Result ou Wait avec prudence et avec une documentation adéquate.
• Code de tâche parallèle : Pour les tâches parallèles non asynchrones, .Result et Wait conviennent.

En suivant ces directives, les développeurs peuvent améliorer la gestion des exceptions, éviter les blocages et écrire du code asynchrone plus robuste et plus maintenable.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!