Pourquoi n'attend pas sur Task.WhenAll lance une AggregateException?

Dans ce code:

private async void button1_Click(object sender, EventArgs e) {
    try {
        await Task.WhenAll(DoLongThingAsyncEx1(), DoLongThingAsyncEx2());
    }
    catch (Exception ex) {
        // Expect AggregateException, but got InvalidTimeZoneException
    }
}

Task DoLongThingAsyncEx1() {
    return Task.Run(() => { throw new InvalidTimeZoneException(); });
}

Task DoLongThingAsyncEx2() {
    return Task.Run(() => { throw new InvalidOperation();});
}

Je m'attendais WhenAllà créer et à lancer un AggregateException, car au moins l'une des tâches qu'il attendait a lancé une exception. Au lieu de cela, je récupère une seule exception lancée par l'une des tâches.

Ne WhenAllcrée pas toujours un AggregateException?

Je ne me souviens pas exactement où, mais j'ai lu quelque part qu'avec les nouveaux mots-clés async / await , ils déploient le AggregateExceptiondans l'exception réelle.

Ainsi, dans le bloc catch, vous obtenez l'exception réelle et non l'agrégée. Cela nous aide à écrire du code plus naturel et intuitif.

Cela était également nécessaire pour faciliter la conversion du code existant en utilisant async / await où le grand nombre de code attend des exceptions spécifiques et non des exceptions agrégées.

-- Éditer --

Je l'ai:

An Async Primer par Bill Wagner

Bill Wagner a déclaré: (dans When Exceptions Happen )

... Lorsque vous utilisez await, le code généré par le compilateur désencapsule AggregateException et lève l'exception sous-jacente. En tirant parti de await, vous évitez le travail supplémentaire pour gérer le type AggregateException utilisé par Task.Result, Task.Wait et d'autres méthodes Wait définies dans la classe Task. C'est une autre raison d'utiliser await au lieu des méthodes Task sous-jacentes ...

Je sais que c'est une question à laquelle on a déjà répondu, mais la réponse choisie ne résout pas vraiment le problème du PO, alors j'ai pensé que je publierais ceci.

Cette solution vous donne l'exception globale (c'est-à-dire toutes les exceptions qui ont été levées par les différentes tâches) et ne bloque pas (le flux de travail est toujours asynchrone).

async Task Main()
{
    var task = Task.WhenAll(A(), B());

    try
    {
        var results = await task;
        Console.WriteLine(results);
    }
    catch (Exception)
    {
        if (task.Exception != null)
        {
            throw task.Exception;
        }
    }
}

public async Task<int> A()
{
    await Task.Delay(100);
    throw new Exception("A");
}

public async Task<int> B()
{
    await Task.Delay(100);
    throw new Exception("B");
}

La clé est d'enregistrer une référence à la tâche d'agrégation avant de l'attendre, vous pouvez alors accéder à sa propriété Exception qui contient votre AggregateException (même si une seule tâche a levé une exception).

J'espère que cela est toujours utile. Je sais que j'ai eu ce problème aujourd'hui.

Vous pouvez parcourir toutes les tâches pour voir si plusieurs d'entre elles ont généré une exception:

private async Task Example()
{
    var tasks = new [] { DoLongThingAsyncEx1(), DoLongThingAsyncEx2() };

    try 
    {
        await Task.WhenAll(tasks);
    }
    catch (Exception ex) 
    {
        var exceptions = tasks.Where(t => t.Exception != null)
                              .Select(t => t.Exception);
    }
}

private Task DoLongThingAsyncEx1()
{
    return Task.Run(() => { throw new InvalidTimeZoneException(); });
}

private Task DoLongThingAsyncEx2()
{
    return Task.Run(() => { throw new InvalidOperationException(); });
}

Je pensais juste que je développerais la réponse de @ Richiban pour dire que vous pouvez également gérer l'exception AggregateException dans le bloc catch en le référençant à partir de la tâche. Par exemple:

async Task Main()
{
    var task = Task.WhenAll(A(), B());

    try
    {
        var results = await task;
        Console.WriteLine(results);
    }
    catch (Exception ex)
    {
        // This doesn't fire until both tasks
        // are complete. I.e. so after 10 seconds
        // as per the second delay

        // The ex in this instance is the first
        // exception thrown, i.e. "A".
        var firstExceptionThrown = ex;

        // This aggregate contains both "A" and "B".
        var aggregateException = task.Exception;
    }
}

public async Task<int> A()
{
    await Task.Delay(100);
    throw new Exception("A");
}

public async Task<int> B()
{
    // Extra delay to make it clear that the await
    // waits for all tasks to complete, including
    // waiting for this exception.
    await Task.Delay(10000);
    throw new Exception("B");
}

Vous pensez à Task.WaitAll- cela lance un AggregateException.

WhenAll lève simplement la première exception de la liste des exceptions qu'il rencontre.

Beaucoup de bonnes réponses ici, mais j'aimerais tout de même publier ma diatribe car je viens de rencontrer le même problème et j'ai mené des recherches. Ou passez à la version TLDR ci-dessous.

Le problème

Attendre le taskretour par Task.WhenAlllève uniquement la première exception du AggregateExceptionstocké dans task.Exception, même lorsque plusieurs tâches ont échoué.

La documentation actuelle pourTask.WhenAll dire:

Si l'une des tâches fournies se termine dans un état défectueux, la tâche retournée se terminera également dans un état défectueux, où ses exceptions contiendront l'agrégation de l'ensemble d'exceptions déballées de chacune des tâches fournies.

Ce qui est correct, mais cela ne dit rien sur le comportement de "déroulement" mentionné ci-dessus lorsque la tâche retournée est attendue.

Je suppose que les documents ne le mentionnent pas parce que ce comportement n'est pas spécifique àTask.WhenAll .

C'est simplement ce qui Task.Exceptionest de type AggregateExceptionet pour les awaitsuites, il est toujours déballé comme sa première exception intérieure, par conception. C'est génial dans la plupart des cas, car il se Task.Exceptioncompose généralement d'une seule exception interne. Mais considérez ce code:

Task WhenAllWrong()
{
    var tcs = new TaskCompletionSource<DBNull>();
    tcs.TrySetException(new Exception[]
    {
        new InvalidOperationException(),
        new DivideByZeroException()
    });
    return tcs.Task;
}

var task = WhenAllWrong();    
try
{
    await task;
}
catch (Exception exception)
{
    // task.Exception is an AggregateException with 2 inner exception 
    Assert.IsTrue(task.Exception.InnerExceptions.Count == 2);
    Assert.IsInstanceOfType(task.Exception.InnerExceptions[0], typeof(InvalidOperationException));
    Assert.IsInstanceOfType(task.Exception.InnerExceptions[1], typeof(DivideByZeroException));

    // However, the exception that we caught here is 
    // the first exception from the above InnerExceptions list:
    Assert.IsInstanceOfType(exception, typeof(InvalidOperationException));
    Assert.AreSame(exception, task.Exception.InnerExceptions[0]);
}

Ici, une instance de AggregateExceptionest déroulée dans sa première exception interne InvalidOperationExceptionexactement de la même manière que nous l'aurions pu avoir avec Task.WhenAll. Nous aurions pu ne pas observer DivideByZeroExceptionsi nous ne passions pas task.Exception.InnerExceptionsdirectement.

Stephen Toub de Microsoft explique la raison de ce comportement dans le problème GitHub associé :

Ce que j'essayais de faire valoir, c'est que cela a été discuté en profondeur, il y a des années, lorsque ceux-ci ont été ajoutés à l'origine. Nous avons initialement fait ce que vous suggérez, avec la tâche retournée par WhenAll contenant une seule AggregateException qui contenait toutes les exceptions, c'est-à-dire que task.Exception renverrait un wrapper AggregateException qui contenait une autre AggregateException qui contenait alors les exceptions réelles; puis quand elle était attendue, l'exception AggregateException interne serait propagée. La forte rétroaction que nous avons reçue et qui nous a amenés à changer la conception était que a) la grande majorité de ces cas avaient des exceptions assez homogènes, de sorte que la propagation du tout dans un agrégat n'était pas si important, b) la propagation de l'agrégat, puis brisé les attentes concernant les captures. pour les types d'exceptions spécifiques, et c) pour les cas où quelqu'un voulait l'agrégat, il pouvait le faire explicitement avec les deux lignes comme je l'ai écrit. Nous avons également eu des discussions approfondies sur ce que devrait être le comportement de await en ce qui concerne les tâches contenant plusieurs exceptions, et c'est là que nous avons atterri.

Une autre chose importante à noter, ce comportement de déballage est peu profond. C'est-à-dire qu'il ne déroulera que la première exception AggregateException.InnerExceptionset la laissera là, même s'il s'agit d'une instance d'une autre AggregateException. Cela peut ajouter encore une autre couche de confusion. Par exemple, changeons WhenAllWrongcomme ceci:

async Task WhenAllWrong()
{
    await Task.FromException(new AggregateException(
        new InvalidOperationException(),
        new DivideByZeroException()));
}

var task = WhenAllWrong();

try
{
    await task;
}
catch (Exception exception)
{
    // now, task.Exception is an AggregateException with 1 inner exception, 
    // which is itself an instance of AggregateException
    Assert.IsTrue(task.Exception.InnerExceptions.Count == 1);
    Assert.IsInstanceOfType(task.Exception.InnerExceptions[0], typeof(AggregateException));

    // And now the exception that we caught here is that inner AggregateException, 
    // which is also the same object we have thrown from WhenAllWrong:
    var aggregate = exception as AggregateException;
    Assert.IsNotNull(aggregate);
    Assert.AreSame(exception, task.Exception.InnerExceptions[0]);
    Assert.IsInstanceOfType(aggregate.InnerExceptions[0], typeof(InvalidOperationException));
    Assert.IsInstanceOfType(aggregate.InnerExceptions[1], typeof(DivideByZeroException));
}

Une solution (TLDR)

Donc, revenons à await Task.WhenAll(...), ce que je voulais personnellement, c'est pouvoir:

• Obtenez une seule exception si une seule a été lancée;
• Obtenez un AggregateExceptionsi plus d'une exception a été levée collectivement par une ou plusieurs tâches;
• Évitez d'avoir à enregistrer le Taskseul pour vérifier son Task.Exception;
• Propager l'état d'annulation correctement ( Task.IsCanceled), comme quelque chose comme cela ne ferait pas cela: Task t = Task.WhenAll(...); try { await t; } catch { throw t.Exception; }.

J'ai mis en place l'extension suivante pour cela:

public static class TaskExt 
{
    /// <summary>
    /// A workaround for getting all of AggregateException.InnerExceptions with try/await/catch
    /// </summary>
    public static Task WithAggregatedExceptions(this Task @this)
    {
        // using AggregateException.Flatten as a bonus
        return @this.ContinueWith(
            continuationFunction: anteTask =>
                anteTask.IsFaulted &&
                anteTask.Exception is AggregateException ex &&
                (ex.InnerExceptions.Count > 1 || ex.InnerException is AggregateException) ?
                Task.FromException(ex.Flatten()) : anteTask,
            cancellationToken: CancellationToken.None,
            TaskContinuationOptions.ExecuteSynchronously,
            scheduler: TaskScheduler.Default).Unwrap();
    }    
}

Maintenant, ce qui suit fonctionne comme je le souhaite:

try
{
    await Task.WhenAll(
        Task.FromException(new InvalidOperationException()),
        Task.FromException(new DivideByZeroException()))
        .WithAggregatedExceptions();
}
catch (OperationCanceledException) 
{
    Trace.WriteLine("Canceled");
}
catch (AggregateException exception)
{
    Trace.WriteLine("2 or more exceptions");
    // Now the exception that we caught here is an AggregateException, 
    // with two inner exceptions:
    var aggregate = exception as AggregateException;
    Assert.IsNotNull(aggregate);
    Assert.IsInstanceOfType(aggregate.InnerExceptions[0], typeof(InvalidOperationException));
    Assert.IsInstanceOfType(aggregate.InnerExceptions[1], typeof(DivideByZeroException));
}
catch (Exception exception)
{
    Trace.WriteLine($"Just a single exception: ${exception.Message}");
}

Cela fonctionne pour moi

private async Task WhenAllWithExceptions(params Task[] tasks)
{
    var result = await Task.WhenAll(tasks);
    if (result.IsFaulted)
    {
                throw result.Exception;
    }
}

Dans votre code, la première exception est renvoyée par conception, comme expliqué à l' adresse http://blogs.msdn.com/b/pfxteam/archive/2011/09/28/task-exception-handling-in-net-4-5. aspx

Quant à votre question, vous obtiendrez l'exception AggreateException si vous écrivez du code comme celui-ci:

try {
    var result = Task.WhenAll(DoLongThingAsyncEx1(), DoLongThingAsyncEx2()).Result; 
}
catch (Exception ex) {
    // Expect AggregateException here
}