J'ai une asyncméthode qui ne renvoie aucune donnée:

public async Task MyAsyncMethod()
{
    // do some stuff async, don't return any data
}

J'appelle cela à partir d'une autre méthode qui renvoie des données:

public string GetStringData()
{
    MyAsyncMethod(); // this generates a warning and swallows exceptions
    return "hello world";
}

Appeler MyAsyncMethod()sans l'attendre provoque un avertissement « Parce que cet appel n'est pas attendu, la méthode actuelle continue de s'exécuter avant la fin de l'appel » dans Visual Studio. Sur la page de cet avertissement, il est indiqué:

Vous ne devez envisager de supprimer l'avertissement que si vous êtes sûr de ne pas attendre la fin de l'appel asynchrone et que la méthode appelée ne déclenche aucune exception .

Je suis sûr que je ne veux pas attendre la fin de l'appel; Je n'en ai pas besoin ni le temps. Mais l'appel pourrait soulever des exceptions.

Je suis tombé sur ce problème à plusieurs reprises et je suis sûr que c'est un problème commun qui doit avoir une solution commune.

Comment appeler en toute sécurité une méthode asynchrone sans attendre le résultat?

Mettre à jour:

Pour les personnes suggérant que j'attends juste le résultat, il s'agit d'un code qui répond à une requête Web sur notre service Web (API Web ASP.NET). L'attente dans un contexte d'interface utilisateur laisse le thread d'interface utilisateur libre, mais l'attente dans un appel de demande Web attendra que la tâche se termine avant de répondre à la demande, augmentant ainsi les temps de réponse sans raison.

Si vous voulez obtenir l'exception "asynchrone", vous pouvez faire:

  MyAsyncMethod().
    ContinueWith(t => Console.WriteLine(t.Exception),
        TaskContinuationOptions.OnlyOnFaulted);

Cela vous permettra de traiter une exception sur un thread autre que le thread "principal". Cela signifie que vous n'avez pas à "attendre" l'appel MyAsyncMethod()depuis le thread qui appelle MyAsyncMethod; mais, vous permet toujours de faire quelque chose avec une exception - mais seulement si une exception se produit.

Mettre à jour:

techniquement, vous pourriez faire quelque chose de similaire avec await:

try
{
    await MyAsyncMethod().ConfigureAwait(false);
}
catch (Exception ex)
{
    Trace.WriteLine(ex);
}

... ce qui serait utile si vous aviez besoin d'utiliser spécifiquement try/ catch(ou using) mais je trouve que ContinueWithc'est un peu plus explicite parce que vous devez savoir ce que cela ConfigureAwait(false)signifie.

Vous devez d'abord envisager de créer GetStringDataune asyncméthode et de lui faire awaitrenvoyer la tâche MyAsyncMethod.

Si vous êtes absolument sûr que vous n'avez pas besoin de gérer les exceptions MyAsyncMethod ou de savoir quand cela se termine, vous pouvez le faire:

public string GetStringData()
{
  var _ = MyAsyncMethod();
  return "hello world";
}

BTW, ce n'est pas un "problème commun". Il est très rare de vouloir exécuter du code sans se soucier s'il se termine et sans se soucier s'il se termine avec succès.

Mettre à jour:

Puisque vous êtes sur ASP.NET et que vous souhaitez revenir tôt, vous pouvez trouver mon article de blog sur le sujet utile . Cependant, ASP.NET n'a pas été conçu pour cela et il n'y a aucune garantie que votre code s'exécutera après le retour de la réponse. ASP.NET fera de son mieux pour le laisser fonctionner, mais il ne peut pas le garantir.

Donc, c'est une bonne solution pour quelque chose de simple comme jeter un événement dans un journal où cela n'a pas vraiment d' importance si vous en perdez quelques-uns ici et là. Ce n'est pas une bonne solution pour tout type d'opérations critiques pour l'entreprise. Dans ces situations, vous devez adopter une architecture plus complexe, avec un moyen persistant pour enregistrer les opérations (par exemple, Azure Queues, MSMQ) et un processus d'arrière-plan distinct (par exemple, Azure Worker Role, Win32 Service) pour les traiter.

La réponse de Peter Ritchie était ce que je voulais, et l'article de Stephen Cleary sur le retour précoce dans ASP.NET a été très utile.

Cependant, en tant que problème plus général (non spécifique à un contexte ASP.NET), l'application console suivante montre l'utilisation et le comportement de la réponse de Peter en utilisant Task.ContinueWith(...)

static void Main(string[] args)
{
  try
  {
    // output "hello world" as method returns early
    Console.WriteLine(GetStringData());
  }
  catch
  {
    // Exception is NOT caught here
  }
  Console.ReadLine();
}

public static string GetStringData()
{
  MyAsyncMethod().ContinueWith(OnMyAsyncMethodFailed, TaskContinuationOptions.OnlyOnFaulted);
  return "hello world";
}

public static async Task MyAsyncMethod()
{
  await Task.Run(() => { throw new Exception("thrown on background thread"); });
}

public static void OnMyAsyncMethodFailed(Task task)
{
  Exception ex = task.Exception;
  // Deal with exceptions here however you want
}

GetStringData()retourne tôt sans attendre MyAsyncMethod()et les exceptions levées MyAsyncMethod()sont traitées dans OnMyAsyncMethodFailed(Task task)et non dans le try/ catcharoundGetStringData()

Je me retrouve avec cette solution:

public async Task MyAsyncMethod()
{
    // do some stuff async, don't return any data
}

public string GetStringData()
{
    // Run async, no warning, exception are catched
    RunAsync(MyAsyncMethod()); 
    return "hello world";
}

private void RunAsync(Task task)
{
    task.ContinueWith(t =>
    {
        ILog log = ServiceLocator.Current.GetInstance<ILog>();
        log.Error("Unexpected Error", t.Exception);

    }, TaskContinuationOptions.OnlyOnFaulted);
}

C'est ce qu'on appelle le feu et oublier, et il y a une extension pour cela.

Consomme une tâche et n'en fait rien. Utile pour les appels à tirer et oublier aux méthodes asynchrones dans les méthodes asynchrones.

Installez le paquet nuget .

Utilisation:

MyAsyncMethod().Forget();

Je suppose que la question se pose, pourquoi auriez-vous besoin de faire cela? La raison de asyncC # 5.0 est que vous pouvez attendre un résultat. Cette méthode n'est pas réellement asynchrone, mais simplement appelée à la fois afin de ne pas trop interférer avec le thread courant.

Il serait peut-être préférable de démarrer un thread et de le laisser se terminer seul.

Sur les technologies avec des boucles de messages (vous ne savez pas si ASP en fait partie), vous pouvez bloquer la boucle et traiter les messages jusqu'à la fin de la tâche et utiliser ContinueWith pour débloquer le code:

public void WaitForTask(Task task)
{
    DispatcherFrame frame = new DispatcherFrame();
    task.ContinueWith(t => frame.Continue = false));
    Dispatcher.PushFrame(frame);
}

Cette approche est similaire au blocage sur ShowDialog et à la réactivité de l'interface utilisateur.

Je suis en retard à la fête ici, mais il y a une bibliothèque géniale que j'utilise et que je n'ai pas vue référencée dans les autres réponses

https://github.com/brminnick/AsyncAwaitBestPractices

Si vous devez "Fire And Forget" vous appelez la méthode d'extension sur la tâche.

Passer l'action onException à l'appel garantit que vous obtenez le meilleur des deux mondes - pas besoin d'attendre l'exécution et de ralentir vos utilisateurs, tout en conservant la possibilité de gérer l'exception de manière gracieuse.

Dans votre exemple, vous l'utiliseriez comme ceci:

   public string GetStringData()
    {
        MyAsyncMethod().SafeFireAndForget(onException: (exception) =>
                    {
                      //DO STUFF WITH THE EXCEPTION                    
                    }); 
        return "hello world";
    }

Il fournit également des AsyncCommands attendus implémentant ICommand, ce qui est idéal pour ma solution MVVM Xamarin

La solution consiste à démarrer le HttpClient dans une autre tâche d'exécution sans contexte de sincronisation:

var submit = httpClient.PostAsync(uri, new StringContent(body, Encoding.UTF8,"application/json"));
var t = Task.Run(() => submit.ConfigureAwait(false));
await t.ConfigureAwait(false);

Si vous voulez vraiment faire ça. Juste pour adresser "Appeler une méthode asynchrone en C # sans attendre", vous pouvez exécuter la méthode asynchrone à l'intérieur d'un Task.Run. Cette approche attendra la MyAsyncMethodfin.

public string GetStringData()
{
    Task.Run(()=> MyAsyncMethod()).Result;
    return "hello world";
}

awaitdéballe de manière asynchrone la Resulttâche, tandis que l'utilisation de Résultat bloquerait jusqu'à ce que la tâche soit terminée.

La méthode asynchrone renvoie généralement la classe Task. Si vous utilisez une Wait()méthode ou une Resultpropriété et que le code lève une exception - le type d'exception est enveloppé dans AggregateException- vous devez alors interroger Exception.InnerExceptionpour localiser l'exception correcte.

Mais il est également possible d'utiliser à la .GetAwaiter().GetResult()place - il attendra également la tâche asynchrone, mais ne terminera pas l'exception.

Voici donc un petit exemple:

public async Task MyMethodAsync()
{
}

public string GetStringData()
{
    MyMethodAsync().GetAwaiter().GetResult();
    return "test";
}

Vous voudrez peut-être également être en mesure de renvoyer certains paramètres de la fonction asynchrone - cela peut être réalisé en fournissant un supplément Action<return type>dans la fonction asynchrone, par exemple comme ceci:

public string GetStringData()
{
    return MyMethodWithReturnParameterAsync().GetAwaiter().GetResult();
}

public async Task<String> MyMethodWithReturnParameterAsync()
{
    return "test";
}

Veuillez noter que les méthodes asynchrones ont généralement un ASyncnom de suffixe, juste pour éviter la collision entre les fonctions de synchronisation avec le même nom. (Par exemple FileStream.ReadAsync) - J'ai mis à jour les noms de fonctions pour suivre cette recommandation.