Dlaczego nie czeka na Task.WhenAll zgłasza wyjątek AggregateException?

W tym kodzie:

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();});
}

Spodziewałem WhenAllsię, że utworzę i wyrzucę AggregateException, ponieważ co najmniej jedno z zadań, na które oczekiwał, rzuciło wyjątek. Zamiast tego otrzymuję pojedynczy wyjątek zgłoszony przez jedno z zadań.

Nie WhenAllzawsze tworzy AggregateException?

Nie pamiętam dokładnie gdzie, ale gdzieś przeczytałem, że z nowymi słowami kluczowymi async / await rozpakowują one AggregateExceptionw rzeczywisty wyjątek.

Tak więc w bloku catch otrzymujesz rzeczywisty wyjątek, a nie zagregowany. Pomaga nam to pisać bardziej naturalny i intuicyjny kod.

Było to również potrzebne do łatwiejszej konwersji istniejącego kodu do korzystania z async / await, gdzie duża część kodu oczekuje określonych wyjątków, a nie zagregowanych wyjątków.

-- Edytować --

Rozumiem:

An Async Primer autorstwa Billa Wagnera

Bill Wagner powiedział: (w When Exceptions Happen )

... Gdy używasz await, kod wygenerowany przez kompilator rozpakowuje AggregateException i zgłasza bazowy wyjątek. Wykorzystując await, unikasz dodatkowej pracy związanej z obsługą typu AggregateException używanego przez Task.Result, Task.Wait i inne metody Wait zdefiniowane w klasie Task. To kolejny powód, dla którego warto używać await zamiast podstawowych metod Task ....

Wiem, że jest to pytanie, na które już udzielono odpowiedzi, ale wybrana odpowiedź tak naprawdę nie rozwiązuje problemu OP, więc pomyślałem, że opublikuję to.

To rozwiązanie zapewnia zagregowany wyjątek (tj. Wszystkie wyjątki, które zostały zgłoszone przez różne zadania) i nie blokuje (przepływ pracy jest nadal asynchroniczny).

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");
}

Kluczem jest zapisanie odwołania do zadania zagregowanego, zanim zaczekasz, a następnie możesz uzyskać dostęp do jego właściwości Exception, która przechowuje Twój AggregateException (nawet jeśli tylko jedno zadanie zgłosiło wyjątek).

Mam nadzieję, że to jest nadal przydatne. Wiem, że miałem dzisiaj ten problem.

Możesz przejść przez wszystkie zadania, aby sprawdzić, czy więcej niż jedno zgłosiło wyjątek:

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(); });
}

Pomyślałem, że rozszerzę odpowiedź @ Richiban, aby powiedzieć, że możesz również obsłużyć AggregateException w bloku catch, odwołując się do niego z zadania. Na przykład:

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");
}

Myślisz o Task.WaitAll- rzuca AggregateException.

WhenAll po prostu zgłasza pierwszy wyjątek z listy wyjątków, które napotka.

Wiele dobrych odpowiedzi tutaj, ale nadal chciałbym opublikować mój rant, ponieważ właśnie natknąłem się na ten sam problem i przeprowadziłem badania. Lub przejdź do wersji TLDR poniżej.

Problem

Oczekiwanie na taskzwrócone przez Task.WhenAlltylko zgłasza pierwszy wyjątek AggregateExceptionprzechowywanego w task.Exception, nawet jeśli wystąpił błąd wielu zadań.

Te obecne docs dlaTask.WhenAll słownie:

Jeśli którekolwiek z dostarczonych zadań zakończy się w stanie błędu, zwrócone zadanie również zakończy się w stanie Niepowodzenie, w którym jego wyjątki będą zawierać agregację zestawu nieopakowanych wyjątków z każdego z podanych zadań.

Co jest poprawne, ale nie mówi nic o wspomnianym wcześniej zachowaniu „rozpakowywania”, kiedy oczekuje się zwróconego zadania.

Przypuszczam, że doktorzy nie wspominają o tym, ponieważ to zachowanie nie jest specyficzne dlaTask.WhenAll .

Jest to po prostu Task.Exceptiontyp AggregateExceptioni dla awaitkontynuacji zawsze zostaje rozpakowane jako pierwszy wewnętrzny wyjątek, zgodnie z projektem. Jest to świetne w większości przypadków, ponieważ zwykle Task.Exceptionskłada się tylko z jednego wewnętrznego wyjątku. Ale rozważ ten kod:

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]);
}

W tym przypadku wystąpienie polecenia AggregateExceptionzostaje rozpakowane do pierwszego wewnętrznego wyjątku InvalidOperationExceptionw dokładnie taki sam sposób, w jaki moglibyśmy go mieć Task.WhenAll. Moglibyśmy nie obserwować DivideByZeroException, gdybyśmy nie przeszli task.Exception.InnerExceptionsbezpośrednio.

Stephen Toub z Microsoftu wyjaśnia przyczynę tego zachowania w powiązanym problemie z GitHub :

Chodzi mi o to, że zostało to szczegółowo omówione lata temu, kiedy zostały one pierwotnie dodane. Pierwotnie zrobiliśmy to, co sugerujesz, z Task zwróconym z WhenAll zawierającym pojedynczy AggregateException, który zawierał wszystkie wyjątki, tj. Task.Exception zwrócił opakowanie AggregateException, które zawierało inny AggregateException, który następnie zawierał rzeczywiste wyjątki; wtedy, gdy był oczekiwany, zostanie propagowany wewnętrzny wyjątek AggregateException. Silna informacja zwrotna, którą otrzymaliśmy, która skłoniła nas do zmiany projektu, była taka, że ​​a) zdecydowana większość takich przypadków miała dość jednorodne wyjątki, takie że propagowanie wszystkiego w sumie nie było tak ważne, b) propagowanie agregatu, a następnie przełamanie oczekiwań dotyczących połowów dla określonych typów wyjątków, oraz c) w przypadkach, w których ktoś chciał zagregować, mógł to zrobić wyraźnie z dwoma wierszami, tak jak napisałem. Przeprowadziliśmy również obszerne dyskusje na temat tego, jakie powinno być zachowanie await w odniesieniu do zadań zawierających wiele wyjątków i na tym wylądowaliśmy.

Jeszcze jedna ważna rzecz, na którą należy zwrócić uwagę, to zachowanie podczas rozpakowywania jest płytkie. Oznacza to, że tylko rozpakuje pierwszy wyjątek AggregateException.InnerExceptionsi pozostawi go tam, nawet jeśli jest to wystąpienie innego AggregateException. Może to dodać kolejną warstwę zamieszania. Na przykład zmieńmy w WhenAllWrongten sposób:

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));
}

Rozwiązanie (TLDR)

Wracając do await Task.WhenAll(...)tego, czego osobiście chciałem, to móc:

• Uzyskaj pojedynczy wyjątek, jeśli tylko jeden został zgłoszony;
• Uzyskaj, AggregateExceptionjeśli więcej niż jeden wyjątek został zgłoszony łącznie przez jedno lub więcej zadań;
• Unikaj konieczności zapisywania Taskjedynego w celu sprawdzenia jego Task.Exception;
• Propagować status anulowania prawidłowo ( Task.IsCanceled), a coś takiego nie zrobi, że: Task t = Task.WhenAll(...); try { await t; } catch { throw t.Exception; }.

Przygotowałem do tego następujące rozszerzenie:

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();
    }    
}

Teraz działa tak, jak chcę:

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}");
}

To działa dla mnie

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

W Twoim kodzie pierwszy wyjątek jest zwracany zgodnie z projektem, jak wyjaśniono na stronie http://blogs.msdn.com/b/pfxteam/archive/2011/09/28/task-exception-handling-in-net-4-5. aspx

Jeśli chodzi o twoje pytanie, otrzymasz AggreateException, jeśli napiszesz taki kod:

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