How are exceptions handled in tasks and async methods? What happens with Task.WhenAll, unobserved exceptions and async void?

1. How the builder stores exceptions

// Generated MoveNext (simplified)
try { /* body */ }
catch (Exception ex)
{
    state = -2;
    builder.SetException(ex);   // OCE -> TrySetCanceled; otherwise TrySetException (Faulted)
    return;
}

SetException stores the exception in the task's ExceptionHolder wrapped in an ExceptionDispatchInfo, so when await calls GetResult(), the runtime rethrows it with the original stack plus a --- End of stack trace from previous location --- marker. Modern .NET also trims async state machine frames for readable stack traces.

2. Why await throws only one

Most code wants catch (HttpRequestException) to work after await, so await unwraps to the first inner exception. The task still holds all of them in Task.Exception, an AggregateException. You can flatten nested aggregates with ae.Flatten() and handle selectively with ae.Handle(e => ...).

3. Eager validation without losing async

public Task<Report> BuildAsync(string id, CancellationToken ct)
{
    ArgumentException.ThrowIfNullOrEmpty(id);   // thrown synchronously to the caller
    return BuildCoreAsync(id, ct);

    async Task<Report> BuildCoreAsync(string id, CancellationToken ct)
    {
        var data = await _repo.LoadAsync(id, ct);
        return Render(data);
    }
}

4. The unobserved-exception mechanism

• A faulted task that hasn't been observed keeps a finalisable "exception holder".
• When the task becomes unreachable and the GC finalises the holder, TaskScheduler.UnobservedTaskException is raised.
• Timing depends on GC, so it's unsuitable as primary alerting, but useful as a safety net log.
• Calling e.SetObserved() marks it handled. In .NET Framework 4.0 the default was to crash; 4.5+ changed it to ignore.

5. async void in detail

async void OnClick(object? s, EventArgs e)   // OK: event handler
{
    try { await SaveAsync(); }
    catch (Exception ex) { ShowError(ex); }   // must handle here: nobody can catch it outside
}

AsyncVoidMethodBuilder notifies the SynchronizationContext of operation start/completion and posts exceptions to it. With no context (ASP.NET Core, console), exceptions are rethrown on the thread pool → unhandled → crash. Lambdas passed to Action parameters (e.g. list.ForEach(async x => ...), Timer callbacks) are silently async void.

6. Global safety nets

7. Version notes

8. Try it yourself

1. Run the code example and compare the single caught exception with the full inner exception list.
2. Make WhenAll include one canceled and one faulted task; check the resulting status.
3. Call Task.Run(() => throw new OperationCanceledException(otherToken), token) and check whether it ends Faulted or Canceled.
4. Create a faulted task, drop the reference, call GC.Collect(); GC.WaitForPendingFinalizers(); and watch UnobservedTaskException fire.
5. Write list.ForEach(async x => { await Task.Delay(1); throw new Exception(); }); in a console app and observe the crash.
6. Add a BackgroundService that throws and observe the host stopping.

TaskScheduler.UnobservedTaskException += (_, e) =>
{
    Console.WriteLine($"Unobserved: {e.Exception.InnerException?.Message}");
    e.SetObserved();
};

Task[] uploads =
[
    UploadAsync("a.csv", fail: false),
    UploadAsync("b.csv", fail: true),
    UploadAsync("c.csv", fail: true),
];

Task all = Task.WhenAll(uploads);
try
{
    await all;
}
catch (Exception first)
{
    Console.WriteLine($"await threw only: {first.Message}");
    foreach (var ex in all.Exception!.InnerExceptions)
        Console.WriteLine($"  failure: {ex.Message}");
}

// Cancellation gives Canceled, not Faulted.
using var cts = new CancellationTokenSource();
cts.Cancel();
Task cancelled = Task.Delay(1000, cts.Token);
try { await cancelled; } catch (OperationCanceledException) { }
Console.WriteLine($"Status: {cancelled.Status}");

static async Task UploadAsync(string file, bool fail)
{
    await Task.Delay(20);
    if (fail) throw new IOException($"{file} upload failed");
}