Exceptions in Async Code

A synchronous method that fails throws where it fails, and the exception travels up the call stack until something catches it. Asynchronous methods cannot do that. By the time an HTTP call fails, the method that started it has already returned a task and the stack that called it may be long gone.

So the failure is stored instead. The task is marked as faulted and it holds the exception. Nothing is thrown at the moment of failure.

The exception comes out when you await the task. At that point await inspects the task, finds the stored exception, and throws it into your method at the line of the await. This is why try and catch around an await behave the way you expect, even though the failure happened somewhere else entirely, possibly on another thread.

public async Task<string> ConfirmAsync(int orderId)
{
    try
    {
        Order order = await _orders.GetAsync(orderId);

        await _payments.ChargeAsync(order.Total, order.PaymentMethodId);
        await _orders.MarkPaidAsync(order.Id);

        return $"Order {order.Reference} paid.";
    }
    catch (PaymentDeclinedException ex)
    {
        // Expected outcome of a payment attempt. Handle it, do not treat it as a crash.
        _logger.LogInformation(ex, "Payment declined for order {OrderId}.", orderId);

        return "Payment was declined.";
    }
    catch (HttpRequestException ex)
    {
        // The provider was unreachable. Different problem, different response.
        _logger.LogError(ex, "Payment provider unreachable for order {OrderId}.", orderId);

        throw;
    }
}

• The try block contains three awaits. A failure in any of them is thrown at its own await line, so one try covers all three.
• ChargeAsync may have failed on a thread pool thread several milliseconds ago. The exception was parked on the task and handed to your catch when you awaited. The stack trace still shows where it was originally thrown.
• Two catch blocks distinguish two genuinely different situations. A declined card is a business outcome the caller can act on. An unreachable provider is an infrastructure fault.
• throw on its own rethrows the exception with its original stack trace intact. Writing throw ex instead resets the trace to this line and loses where the problem actually started.
• MarkPaidAsync never runs if ChargeAsync throws, exactly as in synchronous code. Control flow is unchanged by the awaits.

public async Task NotifyAllAsync(IReadOnlyList<Order> orders)
{
    List<Task> sends = orders
        .Select(order => _email.SendConfirmationAsync(order))
        .ToList();

    Task all = Task.WhenAll(sends);

    try
    {
        await all;
    }
    catch (Exception)
    {
        // await threw ONE exception. There may be more.
        // all.Exception is an AggregateException holding every failure.
        IReadOnlyList<Exception> failures =
            all.Exception?.InnerExceptions ?? new List<Exception>();

        foreach (Exception failure in failures)
        {
            _logger.LogError(failure, "Confirmation email failed.");
        }

        // Alternatively, inspect each task individually to know which order failed.
        for (int i = 0; i < sends.Count; i++)
        {
            if (sends[i].IsFaulted)
            {
                _logger.LogError(
                    sends[i].Exception,
                    "Confirmation failed for order {Reference}.",
                    orders[i].Reference);
            }
        }

        throw;
    }
}

• Task.WhenAll waits for every task. If four of them fail, all four failures are recorded, but await can only throw one exception — so it throws the first.
• The task variable is kept in a local, which is the part people miss. Writing await Task.WhenAll(sends) directly gives you no way to reach the combined result afterwards, and the other failures are unreachable.
• all.Exception is an AggregateException. Its InnerExceptions collection holds every failure from every task. That is where the ones await did not show you are waiting.
• The second loop pairs each task with the order it belongs to, using the index. AggregateException tells you what went wrong; only the task list tells you which item it went wrong for, which is usually what you need to retry or report.
• Exception is caught rather than a specific type only because the aim here is to observe all failures before deciding. The bare throw preserves the original exception and stack trace for the caller.
• A subtlety worth knowing: if one of these tasks is cancelled rather than faulted, await Task.WhenAll throws OperationCanceledException, and a cancelled task contributes nothing to Exception. Check IsCanceled as well when both are possible.