Quand devriez-vous utiliser « wait » au lieu de « Task.Result » pour les tâches terminées ?

await vs. Task.Result pour les tâches terminées : meilleures pratiques

Le « Concurrency in C# Cookbook » montre un modèle de gestion des tâches terminées :

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

Ce code utilise Task.WhenAny pour déterminer si downloadTask (un httpclient.GetStringAsync appel) se termine avant timeoutTask (une Task.Delay opération).

Pourquoi utiliser await downloadTask au lieu de simplement renvoyer downloadTask.Result ? Les raisons sont cruciales :

Gestion des exceptions :

• await évite les complexités de AggregateException. Task.Result ou Task.Wait() enveloppe les exceptions dans AggregateException, obscurcissant ainsi la cause première. Le code asynchrone devrait idéalement gérer les exceptions directement, ce qui en fait await la solution la plus propre.

Évitement des impasses :

• L'utilisation de Task.Result ou Task.Wait() dans une méthode asynchrone peut conduire à des blocages. await est conçu pour les contextes asynchrones et évite cet écueil courant.

Résumé des meilleures pratiques :

• Favorisez await le code d'application asynchrone pour une meilleure gestion des exceptions et une meilleure prévention des blocages.
• Bien que Task.Result ou Task.Wait() puissent être acceptables dans le code utilitaire (avec des commentaires clairs expliquant la justification), il est généralement préférable de les éviter.
• Task.Result et Task.Wait() peuvent être envisagés pour des scénarios de tâches parallèles où le blocage synchrone est acceptable et compris.

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!