Je veux vous attendent afin de jeter AggregateException, pas seulement la première Exception

Lors de l'attente d'une reproché à la tâche (celui qui a une exception), await va renvoyer la stockées exception. Si la réserve d'exception est un AggregateException il va renvoyer le premier et jeter le reste.

Comment pouvons-nous utiliser await et en même temps jeter l'original AggregateException de façon à ne pas perdre accidentellement les informations d'erreur?

Noter qu'il est bien sûr possible de penser hacky solutions pour cela (par exemple try-catch autour de la await, puis d'appeler Task.Wait). Je vous souhaite vraiment de trouver une solution propre. Quelle est la meilleure pratique ici?

Je pensais de l'aide personnalisé awaiter mais le haut- TaskAwaiter contient beaucoup de magie que je ne suis pas sûr de la façon de reproduire intégralement. Il appelle interne de l'Api sur les TPL types. Je n'ai pas non voulez de reproduire tout cela.

Voici une petite repro si vous voulez jouer avec elle:

static void Main()
{
    Run().Wait();
}

static async Task Run()
{
    Task[] tasks = new[] { CreateTask("ex1"), CreateTask("ex2") };
    await Task.WhenAll(tasks);
}

static Task CreateTask(string message)
{
    return Task.Factory.StartNew(() => { throw new Exception(message); });
}

Seulement l'une des deux exceptions sont jetés dans Run.

Noter, que d'autres questions sur un Débordement de Pile à ne pas traiter de ce problème spécifique. Soyez prudent lors de l'suggérant des doublons.

Avez-vous vu cette entrée de blog expliquant pourquoi ils ont choisi de mettre en œuvre la gestion des exceptions pour await comme ils l'ont fait? blogs.msdn.com/b/pfxteam/archive/2011/09/28/10217876.aspx
Oui, merci. J'ai un peu d'accord avec ce raisonnement pour le cas général, mais mon cas d'utilisation n'est pas couverte.
"Dans tous les cas, la Tâche de l'Exception de la propriété renvoie toujours une AggregateException qui contient toutes les exceptions, de sorte que vous pouvez attraper quel est lancée et revenir pour consulter la Tâche.Exception en cas de besoin."

InformationsquelleAutor usr | 2013-08-19

async-await c#c#-5.0 task-parallel-library

23

Je suis en désaccord avec l'implication dans votre question titre que awaitle comportement indésirable. Il a de sens que dans la grande majorité des scénarios. Dans un WhenAll situation, combien de fois avez-vous vraiment besoin de savoir tous les détails de l'erreur, par opposition à un seul?

La principale difficulté de la AggregateException est la gestion des exceptions, c'est à dire, vous perdez la capacité d'attraper un type particulier.

Cela dit, vous pouvez obtenir le comportement que vous voulez avec une méthode d'extension:
```
public static async Task WithAggregateException(this Task source)
{
  try
  {
    await source.ConfigureAwait(false);
  }
  catch
  {
    //source.Exception may be null if the task was canceled.
    if (source.Exception == null)
      throw;

    //EDI preserves the original exception's stack trace, if any.
    ExceptionDispatchInfo.Capture(source.Exception).Throw();
  }
}
```
- L'obtention de toutes les exceptions est important pour le diagnostic. Je ne veux plus jamais manquer nullrefs et ainsi de suite. Ils doivent être enregistrés. Manutention une exception est un scénario différent cependant. Btw, la solution fonctionne très bien. Merci.
- Si vous parlez de la fatal ou boneheaded exceptions, je recommande l'utilisation de haut-niveau des gestionnaires (UnobservedTaskException, de l'Application des gestionnaires) au lieu de la répétition des try/catch blocs.
- Je suis d'accord la plupart du temps. Le scénario que j'ai en tête est une erreur de niveau supérieur gestionnaire en effet (il n'est de journal se bloque). Mais le crash de l'info doit en quelque sorte y arriver. UnobservedTaskException et l'Application gestionnaires ne garantit pas que dans la présence de l'attendent, car les erreurs peuvent finir observé, mais avalé.; Je suis très nerveux quand je vois des erreurs d'ingestion. J'ai vu trop de cas où la production a souffert de graves erreurs pendant des mois et personne ne l'a remarqué.
- UnobservedTaskException est toujours levé pour les non observées des exceptions (il n'a tout simplement pas bloquer le processus plus). Le seul cas où vous avez observé, avalé exception est WhenAll, et qu'il ne se produit lorsque vous avez plusieurs exceptions, dont l'une est pas d'ingestion. Tu as vraiment de essayer pour ignorer les exceptions avec await.
- J'avais prévu l'ajout d'une réponse de ma propre détaillant les différentes approches possibles. J'ai trouvé un peu plus dans l'intervalle. Mais qui sait quand je vais recevoir autour de faire.
- Je sais ce que ConfigureAwait n' ) mais comment se fait-il aide également dans le fait de lancer L'ensemble des exceptions ? Je veux dire , Comment est-ce lié ?
- Il n'a pas. Il est juste de dire que le contexte n'a pas à être repris sur throw.
- La raison pourquoi vouloir connaître tous les détails de l'exception est similaire à pourquoi il y a CA1031: Ne pas attraper général, les types d'exception. Comme un "catch all" clause await peut masquer des exceptions sans jamais te trouver.. ou seulement après beaucoup de temps passé sur le débogage. Fourre-tout clauses utilisées à être désapprouvées - et je pense qu'elles le sont. Pourquoi les mêmes raisons s'appliquent pas à await Task.WhenAll?
- Dans la grande majorité des async code, await fait la bonne chose en ne prenant en compte qu'une seule exception à la règle. WhenAll est la seule situation où ce ne peut pas être la meilleure solution. Lorsque j'ai utilisé WhenAll, je n'ai presque jamais besoin de connaître toutes les exceptions, juste qu'il n'y a un exception. Donc await fait la bonne chose de la vaste, la vaste majorité du temps. C'est différent de catch { } uniquement parce que le supplémentaire exceptions sont ignorés, pas tous d'entre eux.
- Je suis pas clair de savoir si vous êtes en plaidant en faveur de la conception actuelle comme la meilleure conception possible ou tout simplement le meilleur "vous" (MS) pourrait choisir compte tenu de contraintes préexistantes (Tâche de lancer AggregateException..). Si c'est le tard, alors je pense que ce serait bien si on pouvait aller de l'avant, comment la conception mieux. Je reconnais pleinement qu'une telle transition pourrait prendre des années à mettre en œuvre. Si c'est l'ancien (le meilleur design possible), puis je ne suis pas d'accord.
- Je pense que c'est la meilleure conception possible. (BTW, je ne travaille pas pour MS et n'ont jamais). N'hésitez pas à écrire un autre de conception et de poster un lien, et je pourrais changer mon esprit. 🙂
- sur MS, désolé, je pense que j'ai mélangé avec M. Toub :/ en ce qui concerne la conception: la Tâche doit toujours renvoyer une exception directement (sans habillage comme AggregateException par l'infrastructure), toujours une seule exception directement. Les cas spéciaux comme Task.WhenAll devriez jeter un AggregateException ou peut-être un plus spécifiques exception comme ParallelWorkJoinException (ce qui serait enveloppez 1-les exceptions - 1 pour chaque Tâche qui a échoué). await serait alors pas besoin de déballer une exception. Même comportement que de maintenant pour 99% des cas, des cas spéciaux obtenir évidente, un traitement spécial - droit de l'avant.
- La tâche a deux utilisations principales: l'une en tant que "futur" pour le code asynchrone, et l'autre comme une "unité de travail" pour le code parallèle. Je pense que votre approche nécessiterait une mutable/gelé AggregateException au moins. Hésitez pas à postez votre idée de discussion. De côté: techniquement, await ne pas déballer le AggregateException, mais c'est un OK modèle mental.
- Laissez-nous continuer cette discussion dans le chat.
- Prendre en compte le fait que source.Exception pourrait être une référence null lors de l'annulation.
- Excellent, merci! J'ai mis à jour le code de la réponse.
InformationsquelleAutor Stephen Cleary

Je sais je suis en retard mais j'ai trouvé ce joli petit truc qui fait ce que vous voulez. Depuis l'ensemble des exceptions sont disponibles sur attendue de la Tâche, à l'appel de cette Tâche d'Attente ou un .Résultat de jeter un agrégat d'exception.

    static void Main(string[] args)
    {
        var task = Run();
        task.Wait();
    }
    public static async Task Run()
    {

        Task[] tasks = new[] { CreateTask("ex1"), CreateTask("ex2") };
        var compositeTask = Task.WhenAll(tasks);
        try
        {
            await compositeTask.ContinueWith((antecedant) => { }, TaskContinuationOptions.ExecuteSynchronously);
            compositeTask.Wait();
        }
        catch (AggregateException aex)
        {
            foreach (var ex in aex.InnerExceptions)
            {
                Console.WriteLine(ex.Message);
            }
        }
    }

    static Task CreateTask(string message)
    {
        return Task.Factory.StartNew(() => { throw new Exception(message); });
    }

InformationsquelleAutor adonthy

3

La Gestion Des Exceptions (Task Parallel Library)

Je pourrais en dire plus mais il serait juste de rembourrage. Jouer avec elle, il ne fonctionne pas comme ils disent. Vous avez juste à être prudent.

peut-être que vous voulez que ce

Dieu (Jon Skeet) explique attendent la gestion des exceptions

(personnellement je peur de l'attendent, mais c'est juste ma préférence)

en réponse à des commentaires (trop long pour un commentaire de réponse)

Ensuite utiliser les threads comme votre point de départ pour un analogue de l'argument que les meilleures pratiques, il y aura la source de pour ici.

Exceptions heureusement avoir avalé, à moins que vous mettre en œuvre le code pour les passer (par exemple le modèle asynchrone qui l'attendent est preumably emballage ... vous les ajoutez à un événement args objet lorsque vous soulevez un événement). Quand vous avez un scénario où vous lancez un nombre arbitraire de threads et de l'exécuter sur eux, vous n'avez aucun contrôle sur l'ordre ou le point où vous mettez fin à chaque thread. En outre, vous de ne jamais utiliser ce modèle si un message d'erreur sur l'un était pertinent à l'autre. À cet effet, il vous est fortement ce qui implique que l'exécution de la reste est completley indépendant - c'est à dire vous sont fortement ce qui implique que les exceptions à ces fils ont déjà été traitées comme des exceptions. Si vous voulez faire quelque chose au-delà de la gestion des exceptions dans ces fils dans le fils, ils se produisent dans (ce qui est bizzarre), vous devez les ajouter à un système de blocage de la collection qui est passé par référence vous ne les considérant plus comme des exceptions comme des exceptions, mais comme un élément d'information - l'utilisation concomitante de sac, enveloppez-le d'exception dans l'info dont vous avez besoin pour identifier le contexte, il est venu de qui aurait été adoptée dans le.

Ne pas confondre votre cas d'utilisation.
- Le premier lien ne traite pas avec await. Le 2ème contient une réponse valable. Merci. Je vais laisser les autres réponses dans quelques jours parce que j'ai envie de découvrir le mieux la solution.
- le truc c'est que je ne suis d'accord avec votre cas d'utilisation. Je pense que lorsque vous utilisez attendent que vous êtes en supposant que chaque tâche gère ses propres exceptions - attendent vous dit que quelque chose s'est brisé dans une opération où vous ne pouvez pas annuler les autres tâches (c'est à dire qu'ils doivent être indépendants). Ou, au moins, je pense que c'est assumé dans son modèle. Si vous voulez gérer les exceptions à l'extérieur de la tâche, alors vous devriez utiliser la structure supérieure. Je devrais probablement de explique que. Aussi, si vous voulez globale exception - la question - la première devrait être votre choix.
- Le top modèle comporte un blocage qui est une tout autre cas d'utilisation d'attendre les adresses. Une utilisation valide de cas mais pas le mien - j'ai besoin d'async IO et non-bloquant ici.; Aussi, les tâches ne sont pas nécessairement gérer leurs propres erreurs. Si c'était le cas nous n'aurions jamais besoin de propagation d'erreur. Les erreurs sont censés, de propager, de sorte que le flux de contrôle est abandonnée. Tout ce que je veux est tous des erreurs, et pas seulement arbitraire.
- mis à jour ... ofc une tâche gère ses propres erreurs ... une tâche d'une unité d'encapsulation autour d'une unité de travail. Le travail de la manipulation ses exceptions que je dirais est le plus definatley une partie de ce ou que vous êtes la création d'un système de blocage de cauchemar pour vous-même comme 100 threads jeter toutes les exceptions et bloquer sur un bout de code, à moins qu'il n'ai aucun état, à quel point u se rendraient compte que l'essentiel se trouve dans la tâche elle-même de toute façon ... ou un compromis avec moi et passer dans un lambda de traiter l'exception.
- la référence à dieu de l'article est cassé (
- codeblog.jonskeet.royaume-uni/2011/06/22/... .... dieu im opiniâtre à la fois
InformationsquelleAutor John Nicholas

Je ne sais pas si je me suis permis de résumer les deux meilleures solutions (à mon avis) le problème présenté dans cette très intéressante question, les réponses de M. Stephen Cleary et M. adonthy. J'ai modifié légèrement l'API par l'ajout d'un paramètre preserveAggregate, dans une tentative pour être cohérent avec la construction unique-dans l'option de configuration, la ConfigureAwait. Ces configurations sont chainable, par exemple:

await Task.WhenAll(tasks).ConfigureException(true).ConfigureAwait(false);

Ici est M. Stephen Cleary du version (légèrement modifié):

public static class TaskConfigurationExtensions
{
    public static async Task ConfigureException(this Task task, bool preserveAggregate)
    {
        try
        {
            await task.ConfigureAwait(false); //Because the context doesn't have to be resumed on to throw.
        }
        catch
        {
            if (preserveAggregate) throw task.Exception;
            throw;
        }
    }
    public static async Task<T> ConfigureException<T>(this Task<T> task, bool preserveAggregate)
    {
        try
        {
            return await task.ConfigureAwait(false);
        }
        catch
        {
            if (preserveAggregate) throw task.Exception;
            throw;
        }
    }
}

Et voici M. adonthy de l' version (légèrement modifié):

public static class TaskConfigurationExtensions
{
    private static void Empty<T>(T value) { }
    public static async Task ConfigureException(this Task task, bool preserveAggregate)
    {
        if (preserveAggregate)
        {
            await task
                .ContinueWith(Empty, TaskContinuationOptions.ExecuteSynchronously)
                .ConfigureAwait(false);
            task.Wait();
            return;
        }
        await task.ConfigureAwait(false);
    }
    public static async Task<T> ConfigureException<T>(this Task<T> task, bool preserveAggregate)
    {
        if (preserveAggregate)
        {
            await task
                .ContinueWith(Empty, TaskContinuationOptions.ExecuteSynchronously)
                .ConfigureAwait(false);
            return task.Result;
        }
        return await task.ConfigureAwait(false);
    }
}

Aussi loin que je peux dire que les deux implémentations sont équivalentes et excellent.

InformationsquelleAutor Theodor Zoulias

Je ne veux pas abandonner la pratique à seulement attraper les exceptions je pense. Ce qui m'amène à la suite de la méthode d'extension:

public static async Task NoSwallow<TException>(this Task task) where TException : Exception {
    try {
        await task;
    } catch (TException) {
        var unexpectedEx = task.Exception
                               .Flatten()
                               .InnerExceptions
                               .FirstOrDefault(ex => !(ex is TException));
        if (unexpectedEx != null) {
            throw new NotImplementedException(null, unexpectedEx);
        } else {
            throw task.Exception;
        }
    }
}

La consommation de code pourrait aller comme ceci:

try {
    await Task.WhenAll(tasks).NoSwallow<MyException>();
catch (AggregateException ex) {
    HandleExceptions(ex);
}

Un os à tête d'exception aura le même effet que dans synchrone monde, même dans le cas où il est jeté en concomitance avec un MyException par hasard. L'emballage avec NotImplementedException permet de ne pas perdre la trace de la pile d'origine.

InformationsquelleAutor tm1

Vous devez vous connecter pour publier un commentaire.