Marquer une fonction comme asynchrone mais pas d'appels d'attente, des problèmes?

Dans le cas où vous avez une méthode d'interface qui renvoie une tâche et que vous n'avez pas d'attente (ouais ça arrive). Supprimez simplement le mot-clé async et renvoyez Task.CompletedTask

La propriété Task.CompletedTask renvoie une tâche dont Status est défini sur RanToCompletion.

Obtient une tâche qui s'est déjà terminée avec succès.

public class DoSomething2:IMyInterface
{
    public Task DoSomethingAsync()
    {
        doSomethingElse();
        return Task.CompletedTask;
    }
}

Oui, il y a des effets secondaires, le compilateur est en train de mettre en place l'IAsyncStateMachine et produit un tas plus de IL , de plus les futurs développeurs examineront votre code avec ire . En ce qui concerne les autres différences fonctionnelles, je ne peux penser à aucune différence.

Dans votre cas, je pense qu'il pourrait y avoir un problème de blocage du thread principal (et cela dépend si vous vous en souciez ou non) et je pense que ce n'est pas un développeur veut.

Si vous n'avez pas d'appels en attente , vous pouvez faire ce qui suit pour que le thread principal ne soit pas bloqué (> .net 4.0):

public class DoSomething2:IMyInterface
{
     public async Task DoSomethingAsync()
     {
         await Task.Run(()=>doSomethingElse());
     }
}

Les méthodes marquées comme asynchrones fonctionneront de la même manière qu'elles créeront juste un peu de surcharge, car lorsque la méthode est marquée comme async, le compilateur génère essentiellement une machine à états pour cette méthode. (qui dans votre cas ne sera pas utilisée dans certaines méthodes particulières) < / p>

https://foreverframe.net/what-lies-beneath- asyncawait-in-c /

https://msdn.microsoft.com/en-us/magazine /jj991977.aspx

IMyInterface est implémenté par pas mal de classes, mais pour l'une des classes, il n'y a pas d'appels d'attente. Cela posera-t-il des problèmes?

Je vais entrer en territoire dangereux ici et je ne suis pas d'accord avec Eric Lippert. Dans la grande majorité des cas, utiliser async sans await est en effet une erreur et l'avertissement du compilateur est utile. Je dirais que c'est vrai bien au nord de 90% du temps.

Cependant, je dirais que ce scénario est une exception à cette règle. Le problème avec la simple suppression de async / await est que les exceptions sont gérées différemment:

#pragma warning disable 1998
public async Task DoSomethingAsync()
#pragma warning restore 1998
{
  doSomethingElse();
}

// or

public Task DoSomethingAsync()
{
  try
  {
    doSomethingElse();
    return Task.CompletedTask;
  }
  catch (Exception ex)
  {
    return Task.FromException(ex);
  }
}

La sémantique attendue pour un La méthode de retour de Task consiste à capturer des exceptions et à les placer sur la Task renvoyée (enfin, au moins non- exceptions ). Pour conserver cette sémantique, vous devez soit utiliser async (et supprimer l'avertissement) ou un try / catch explicite:

XXX