Fire and Forget approche

Liées à cette réponse,

Si j'ai vraiment envie de "Fire and Forget", une méthode qui retourne une tâche, et (pour la simplicité) supposons que la méthode n'est pas prévu de lancer une quelconque des exceptions. Je peux utiliser la méthode d'extension énumérées dans la réponse:

public static void Forget(this Task task)
{
}

À l'aide de cette approche, si il y a des bugs dans l'action de la Task qui provoquent la levée d'une exception alors quand l'inattendu exception est levée, l'exception sera d'ingestion et de passer inaperçu.

Question: ne Serait-il pas plus approprié dans ce scénario, la méthode d'extension pour être de la forme:

public static async void Forget(this Task task)
{
    await task;
}

De sorte que les erreurs de programmation lever une exception et obtenir de l'escalade (généralement de ramener le processus).

Dans le cas d'une méthode avec des prévu (et ignorable) exceptions près, la méthode aurait besoin pour devenir plus élaboré (en aparté, des suggestions sur la façon de construire une version de cette méthode qui prendrait une liste acceptable et ignorable les types d'exception?)

InformationsquelleAutor Matt Smith | 2014-04-04
  1. 45

    Il dépend de la sémantique que vous voulez. Si vous voulez vous assurer que les exceptions sont notées, alors oui, vous pourriez await la tâche. Mais dans ce cas il n'est pas vraiment "fire and forget".

    Un vrai "fire and forget" - dans le sens que vous ne se soucient pas lorsqu'elle est terminée ou si elle se termine avec succès ou avec d'erreur est extrêmement rare.

    Edit:

    Pour la gestion des exceptions:

    public static async void Forget(this Task task, params Type[] acceptableExceptions)
{
  try
  {
    await task.ConfigureAwait(false);
  }
  catch (Exception ex)
  {
    //TODO: consider whether derived types are also acceptable.
    if (!acceptableExceptions.Contains(ex.GetType()))
      throw;
  }
}

    Remarque que je vous recommande d'utiliser await au lieu de ContinueWith. ContinueWith a une surprenante par défaut planificateur (comme indiqué sur mon blog) et Task.Exception clôturera l'exception dans un AggregateException, rendant le code de gestion d'erreur de plus en plus lourde.

    • Alors, comment puis-je obtenir la sémantique de ne pas se soucier quand quelque chose se termine, mais je fais des soins sur les exceptions? Est-il possible d'avoir ces sémantique sans async void à un certain niveau?
    • Êtes-vous avoir à y penser cela ou je ne suis pas à l'obtenir? Il sonne comme un try/catch est ce que vous auriez besoin. Édité pour montrer un exemple de code.
    • Je pense que @MattSmith l'idée est d'avoir Forget universelle de stub pour fire-and-forget, sans try/catch à l'intérieur. Et de laisser le sélectifs de la gestion de l'exception à la tâche passé à Forget. De cette façon, ce qui fait uncaught serait immédiat jeté sur l'actuel contexte de synchronisation. J'aime ça 🙂
    • et Stephen, de Stephen édition ressemble exactement à ce que je veux. Merci. Et oui, comme Noseratio, je suis à la planification sur l'utilisation de ce comme un universel de stub pour fire-and-forget (à l'exception de ne pas "oublier"et à avaler des exceptions.
    • avec le .ConfigureAwait(false) en place, toutes les exceptions inattendues toujours être affichés à l' SynchronizationContext qui a été actif au début de la méthode?
    • Le catch bloc ne sera pas exécuté dans la capture du contexte (de sorte que toute la journalisation ou ce ne sera pas), mais si l'exception n'est pas acceptable et est renvoyé (throw;), alors oui, l'exception sera (re-)posées sur l' SynchronizationContext qui a été actif au début de Forget.
    • pour avoir un tableau complet, il est sur-relancé par SynchronizationContext.Send de la capture d'contexte pour async void? Tks.
    • Il appelle Post, en fait.
    • En dehors de la source de référence, avez-vous été en mesure de trouver ce lieu important du comportement de async void méthodes documentées n'importe où dans la documentation officielle? J'ai essayé de chercher mais seulement trouvé une troisième partie blog: jaylee.org/post/2012/07/08/...
    • Je ne suis pas au courant de toute la documentation officielle.

    InformationsquelleAutor Stephen Cleary
  2. 3

    Oui si vous étiez intéressé à savoir si ou non la tâche a déclenché une exception alors vous devez await le résultat, mais sur le revers de la médaille, c'est à peu près de défaites le but de "fire & oubliez".

    Dans le cas où vous voulez savoir si quelque chose mauvais qui s'est passé ensuite, la méthode recommandée est d'utiliser une continuation par exemple

    public static void ForgetOrThrow(this Task task)
{
    task.ContinueWith((t) => {
        Console.WriteLine(t.Exception);
    }, TaskContinuationOptions.OnlyOnFaulted);
}
    • "si vous faire Oublier une méthode asynchrone, alors vous essentiellement à réintroduire le même problème"? Que voulez-vous dire-c'est supprimer l'avertissement et ont le même comportement dans le cas d'aucune des exceptions générées. Je suppose que je veux "Fire and Forget", sauf que je ne veux pas ignorer les bugs.
    • il supprime l'avertissement? L'avertissement est dû au fait que de l'extérieur il n'y a pas de await appel sur WorkAsync() de l'intérieur d'une async méthode. Le Forget méthode d'extension (qui ne fait rien) supprime l'avertissement parce que c'est un non-méthode asynchrone. Rendant async nouveau doit être ré-introduction de l'avertissement que vous êtes de retour à l'appel d'une async méthode et ne pas appeler await (à moins que les méthodes d'extension sont traités différemment...).
    • il est async void donc il n'y a rien qui peut être attendu.
    • ah, bien sûr. Mon erreur.
    • Albahari proposé cette même idée dans le Chapitre 23 de C# 5.0 En un Mot comme un moyen de "avaler" une tâche exception non gérée, mais en notant que vous pourriez faire quelque chose avec l'exception, comme l'exploitation forestière...donc j'imagine que ce pourrait être extensible à votre idée d'ignorer certains et re-lancer d'autres. Au lieu de simplement throw t.Exception vous pu "observer" en premier (var ignore = t.Exception; et si pas acceptable, puis jeter: if(reallyBad) {throw t.Exception;} Cela permet à l'acceptables pour être simplement avalé.
    • Arh, mais c'est là que réside la complication. Vous ne voulez pas de simplement renvoyer l'exception dans la poursuite de la tâche, alors vous aurez à remplacer une exception non gérée avec l'autre. Vous devez en quelque sorte le poster retour vers le contexte de synchronisation, comme Stephen Clearys suggestion apparemment atteint.
    • Stephen posté son exceptionnelle réponse après James, donc à partir d'un an, âgé de dialogue point de vue, sa réponse remplace James réponse et mon commentaire. Cela dit, (et je suis loin d'experts Cleary ou quelqu'un d'autre sur cette page), je crois, par l'observation de l'antécédent exception, il n'est plus considéré comme 'non'. Pour citer Albahari: "Un coffre-fort modèle est de re-jeter antecendent exceptions. Aussi longtemps que la suite est Attendu sur, l'exception est de propager et renvoyé au Serveur." (p.942)
    • Je voulais dire pour la postérité que le simple renvoi ne sera pas coupé. Je ne devrais pas avoir abordé spécifiquement pour vous. Comme votre devis états "aussi longtemps Que la suite est attendue dès" - le contexte ici est fire-and-forget, de sorte que vous ne serait pas normalement être en attente sur la poursuite. En effet comme c'est le cas pour le code de cette réponse 🙂

    InformationsquelleAutor James
  3. 3

    Dans le lié à la question j'ai d'abord voulu utiliser static void Forget(this Task task) dans le contexte suivant:

    var task = DoWorkAsync();
QueueAsync(task).Forget();

//...

async Task QueueAsync(Task task)
{
    //keep failed/cancelled tasks in the list
    //they will be observed outside
    _pendingTasks.Add(task);
    await task;
    _pendingTasks.Remove(tasks)
}

    Il avait l'air super, mais j'ai réalisé que fatale exceptions éventuellement jetés par _pendingTasks.Add /_pendingTasks.Remove serait passé inaperçu et a perdu, ce qui n'est pas bon.

    J'ai donc tout simplement fait QueueTask un async void méthode, ce qu'il consiste essentiellement à:

    var task = DoWorkAsync();
QueueAsync(task);

//...

async void QueueAsync(Task task)
{
    //keep failed/cancelled tasks in the list
    //they will be observed outside
    _pendingTasks.Add(task);
    try
    {
        await task;
    }
    catch
    {
        return;
    }
    _pendingTasks.Remove(tasks)
}

    Autant que je n'aime pas le vide catch {}, je pense qu'il fait sens ici.

    Dans ce scénario, en gardant async Task QueueAsync() et à l'aide de async void Forget(this Task task) comme vous proposez serait exagéré, de l'OMI.

    InformationsquelleAutor noseratio