C# Async Méthode Tâche Sans Attendre ou de Retour

J'ai une Interface qui est mis en œuvre dans deux endroits comme:

interface I 
{ 
   Task DoSomething();
}

L'interface a async Task DoSomething méthode de l'API qui est ensuite mise en œuvre dans la classe A comme:

class A : I {....}

class B : I {....}

Dans la classe A, la mise en œuvre de DoSomething est comme ci-dessous et qui est OK:

public async Task DoSomething()
{
    if (...)
    {
        await DoIt();
    }
}

Cependant, dans la classe B, la mise en œuvre de DoSomething() ne doit pas faire n'importe quoi.
Ainsi, sa mise en œuvre ressemble à ceci:

public async Task DoSomething()
{
    //nothing
}

Cette compile, mais je ne suis pas sûr de savoir comment les corriger est de faire quelque chose de ce genre à côté du fait que la méthode est inutile.

Mais le fait d'être "inutile" dans ce cas c'est ok, dans ce cas, puisqu'il est mis en place seulement parce qu'il est tenu par de classe B de la mise en œuvre de l'interface I.

Je me demande si c'est une bonne façon de mettre en œuvre une méthode qui retourne async Tâche, mais n'a pas d'attendre ou de retour? Je sais que cette méthode simple de ne rien faire et de les exécuter de façon synchrone comme il n'y a pas d'appel à attendre.

Mise à JOUR: questions Similaires ont été posées ici et DONC j'ai vérifié tous d'entre eux avant de demander à celui-ci. Aucune demande ce que je me demande si

  • Vous seulement la marque d'une méthode comme async si vous prévoyez sur l'utilisation d'un await (directement) à l'intérieur d'elle. Le fait qu'il renvoie une Task est suffisant pour satisfaire à l'interface; async/await que soient les interfaces.
InformationsquelleAutor pixel | 2017-11-08
  1. 24
    public Task DoSomething()
{
    return Task.CompletedTask;
}

    Pas besoin de la async.

    Si vous utilisez une ancienne version de .NET, utilisez ceci:

    public Task DoSomething()
{
    return Task.FromResult(0);
}

    Si vous trouvez que vous avez besoin de retourner un résultat, mais que vous n'avez pas besoin de await quelque chose, essayez de;

    public Task<Result> DoSomething()
{
    Task.FromResult(new Result())
}

    ou, si vous voulez vraiment utiliser asynchrone (non recommandé);

    public async Task<Result> DoSomething()
{
    return new Result();
}
    • Je reçois que la quatrième option n'est pas recommandée, mais vous ne donnez pas une raison pourquoi?
    • le compilateur va générer un message d'avertissement le long des lignes de "la méthode async manque attendent les opérateurs et exécuté de manière synchrone". Plus important encore, cependant, le compilateur va générer un ensemble de IAsyncStateMachine pour ce qui est autrement une méthode très simple. Un intelligent compilateur peut optimiser cette distance, mais à partir d'une brève visite à sharplab.io, il semble qu'il ya toutes les chances que ce ne sera pas, et sur NET47x il Ece à 259 octets de x86 assemblée pour la méthode async vs 71 pour la synchronisation.
    • Du sens. Merci
    • No need for the async - mais est-il du tort? J'aime un peu le commerce de la return Task.ComletedTask; ligne pour un async mot-clé si elle ne nuire en aucune façon..
    • Comme scotch mentionné, de méthodes asynchrones ont une surcharge associée avec eux et ils devraient seulement être utilisés pour mettre en œuvre quelque chose qui est d'e/S intensives (comme l'écriture d'un fichier externe Http appel). Pour des méthodes simples, ceux ou celles qui sont "Calcul intensif" (comme l'ajout de deux nombres, le calcul de la factorielle de 10^10), async n'aide pas et ainsi créer de supplémentaires de supplémentaires de l'état de frais généraux n'est pas nécessaire.
    InformationsquelleAutor sellotape
  2. 0

    Je vois que la plupart des gens préfèrent laisser de côté la async et l'utilisation Task.ComletedTask à la place. Mais même si await n'est pas utilisé, il y a toujours une grande différence dans la gestion des exceptions

    Considérons l'exemple suivant

    static async Task Main(string[] args)
{

    Task task = test(); //Will throw exception here
    await task;

    Task taskAsync = testWithAsync();
    await taskAsync; //Will throw exception here
}

static Task test()
{
    throw new Exception();
    return Task.CompletedTask; //Unreachable, but left in for the example
}

static async Task testWithAsync()
{
    throw new Exception();
}

    À l'aide de

    test().ContinueWith(...); ou Task.WhenAll(test())

    peut entraîner un comportement inattendu.

    Donc, je préfère async au lieu de Task.CompletedTask ou Task.FromResult.

    InformationsquelleAutor Jan-Fokke