自定义异常被AggregateException包装的原因、判定规则及规避方法

异常被AggregateException包装的核心决定因素 #

• 混用异步与同步阻塞调用：对返回Task/Task<T>的异步方法调用.Wait()、.Result进行阻塞获取结果时，Task内存储的所有异常都会被包装成AggregateException抛出，这是最常见的触发场景。
• 多任务并行等待：使用Task.WhenAll、Task.WaitAll等API同时等待多个任务执行时，只要有至少一个任务抛出异常，所有任务的异常会被打包为AggregateException统一返回。
• 手动封装异常到Task：显式调用Task.FromException、TaskCompletionSource.SetException等API写入异常时，异常会被存储到Task对象中，后续阻塞调用该Task就会触发包装逻辑。

你当前场景的根本原因大概率是SampleMethod中调用AquireToken时，没有使用await做异步等待，而是使用了.Result/.Wait()做阻塞调用。而你直接在SampleMethod中抛异常时，不会经过Task的异常封装逻辑，所以不会被包装。

避免异常被包装的解决方案 #

1. 全程使用await异步等待（优先推荐） #

所有异步方法统一使用await做异步等待，不要混用阻塞调用。await会自动解包Task内存储的异常，直接抛出原始异常，不会生成AggregateException。
只需把SampleMethod中类似如下的阻塞写法：

var token = AquireToken().Result;

修改为异步等待即可：

var token = await AquireToken();

2. 必须阻塞调用时使用GetAwaiter().GetResult() #

如果特殊场景必须同步阻塞等待异步任务结果，不要使用.Wait()/.Result，改用.GetAwaiter().GetResult()，该方法会直接抛出原始异常，不会做AggregateException包装：

// 仅在必须同步调用时使用
var token = AquireToken().GetAwaiter().GetResult();

3. 多任务场景自动解包 #

使用Task.WhenAll并行等待多个任务时，直接用await+对应异常类型捕获即可，await会自动提取第一个匹配的原始异常，不需要手动处理AggregateException：

try
{
    await Task.WhenAll(task1, task2);
}
catch (MyCustomException ex)
{
    // 直接捕获到原始的自定义异常
}

4. 测试临时适配方案 #

如果暂时无法修改业务代码，测试时可以先捕获AggregateException再提取内层自定义异常：

var aggregateEx = await Assert.ThrowsAsync<AggregateException>(async () =>
{
    Environment.SetEnvironmentVariable("BASE_URL", null);
    await serviceUnderTest.SampleMethod(input);
});
var customEx = aggregateEx.Flatten().InnerExceptions.OfType<MyCustomException>().FirstOrDefault();
Assert.NotNull(customEx);
Assert.Equal("Address is not set in Enviroment Variable (BASE_URL)", customEx.Message);

内容的提问来源于stack exchange，提问作者DaveVentura