What are inner exceptions and how do you work with exception chains in .NET? Explain InnerException, GetBaseException, AggregateException (Flatten, Handle, and what await does with it), and wrapper exceptions such as TargetInvocationException and TypeInitializationException.

1. How chains are printed

Exception.ToString() produces:

Orders.OrderPlacementException: Could not place order 42
 ---> Microsoft.EntityFrameworkCore.DbUpdateException: An error occurred while saving the entity changes...
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Violation of UNIQUE KEY constraint 'UQ_Orders_IdempotencyKey'...
   at Microsoft.Data.SqlClient.SqlConnection.OnError(...)
   ...
   --- End of inner exception stack trace ---
   at Microsoft.EntityFrameworkCore.Update.ReaderModificationCommandBatch.ExecuteAsync(...)
   --- End of inner exception stack trace ---
   at Orders.OrderService.PlaceAsync(...)

The innermost exception's stack is printed first under its arrow, then each outer exception's stack. Structured logging providers (Application Insights, Serilog, OpenTelemetry) capture the full ToString() or a structured version with each inner exception, so passing the exception object is essential.

2. GetBaseException semantics

public virtual Exception GetBaseException()
{
    Exception? inner = InnerException;
    Exception back = this;
    while (inner != null) { back = inner; inner = inner.InnerException; }
    return back;
}

AggregateException overrides it: it descends while there is exactly one inner exception and stops at an aggregate with multiple inners (there's no single "base").

3. AggregateException and tasks in depth

• A Task stores exceptions in an internal TaskExceptionHolder. task.Exception always returns an AggregateException (even for one failure).
• Child tasks attached to a parent (TaskCreationOptions.AttachedToParent) propagate as nested aggregates, hence Flatten().
• If a faulted task's exception is never observed (no await, Wait, Result or Exception access), when the task is garbage collected the TaskScheduler.UnobservedTaskException event fires. Since .NET 4.5 it no longer crashes the process by default, which makes fire-and-forget failures silent unless you subscribe to the event.
• await calls TaskAwaiter.GetResult(), which, for faulted tasks, rethrows InnerExceptions[0] with ExceptionDispatchInfo. For canceled tasks it throws TaskCanceledException.

Why does await throw only the first? It mirrors synchronous code: a method can only throw one exception. The design team chose usability for the common single-failure case and left the full set accessible on the task.

4. TypeInitializationException mechanics

The runtime runs a type's .cctor once (under a lock). If it throws, the runtime records the failure and wraps it: every subsequent attempt to access static members or create instances throws a TypeInitializationException with the same inner exception. There's no retry. In ASP.NET Core this can turn a transient start-up problem (a config value missing for a few seconds) into a permanently broken process until restart. Health checks that exercise the type help catch it at deployment time.

5. TargetInvocationException and reflection

MethodInfo.Invoke catches exceptions thrown by the target method and wraps them, so callers can distinguish "reflection failed" (e.g. wrong arguments → ArgumentException, TargetParameterCountException) from "the target method threw". Frameworks that invoke your code via reflection (older MVC filters, some test runners, plugin systems) unwrap it before reporting. In your own reflection code:

try { method.Invoke(target, args); }
catch (TargetInvocationException tie) when (tie.InnerException is not null)
{
    ExceptionDispatchInfo.Capture(tie.InnerException).Throw();   // rethrow original with its stack
}

or use BindingFlags.DoNotWrapExceptions. Compiled expression trees and source-generated invokers don't wrap at all.

6. Designing wrapping at layer boundaries

Wrap when it adds information or abstraction:

• Infrastructure → application: SqlException → PersistenceUnavailableException (callers shouldn't depend on SqlClient).
• Add context: "while importing file X line 42" wrapping a FormatException.

Don't wrap just to change the type at every layer — it creates deep chains with redundant messages. One meaningful wrap per boundary is plenty.

Try it yourself

1. Build a three-level chain and print ToString() and GetBaseException().
2. Run Task.WhenAll with three failing tasks and compare the caught exception vs whenAllTask.Exception.InnerExceptions.
3. Make a static field initialiser throw and access the type twice.
4. Invoke a throwing method via reflection with and without BindingFlags.DoNotWrapExceptions.

// 1. Wrap with context, keep the cause
try
{
    await db.SaveChangesAsync(ct);
}
catch (DbUpdateException ex) when (ex.InnerException is SqlException { Number: 2627 or 2601 })
{
    throw new DuplicateOrderException(order.Id, ex);   // inner = DbUpdateException -> SqlException
}

// 2. See every failure from WhenAll
Task[] tasks = regions.Select(r => LoadRegionAsync(r, ct)).ToArray();
Task all = Task.WhenAll(tasks);
try
{
    await all;
}
catch
{
    foreach (var inner in all.Exception!.InnerExceptions)
        logger.LogError(inner, "Region load failed");
    throw;      // rethrows the first, stack preserved
}

// 3. Handle some, rethrow the rest (synchronous/parallel code)
try
{
    Parallel.ForEach(files, ProcessFile);
}
catch (AggregateException agg)
{
    agg.Flatten().Handle(e =>
    {
        if (e is IOException io) { logger.LogWarning(io, "Skipped file"); return true; }
        return false;       // anything else is rethrown in a new AggregateException
    });
}

// 4. Reflection without the wrapper
object? result = method.Invoke(target, BindingFlags.DoNotWrapExceptions, binder: null,
                               parameters: [], culture: null);