C#中ContinueWith结合类扩展的异常处理差异及代码异味问题

我创建了一个用于结合ContinueWith管理异常的类扩展，代码如下：

public static class ClassExtensions
{
    public static Task<T> ValidateInnerException<T>(this Task<T> task) => task.Exception != null ? throw task.Exception.InnerException ?? task.Exception : task;
}

该扩展有两种调用位置不同的实现方式：

第一种实现 #

public Task<Response> ValidateCall(long periodId)
{
   return _client.Validate(periodId)
    .ContinueWith(t =>
    {
       return t.ValidateInnerException().Result.Adapt<Response>();
    });
}

第二种实现 #

public Task<Response> ValidateCall(long periodId)
{
   return _client.Validate(periodId)
    .ValidateInnerException()
    .ContinueWith(t =>
    {
        return t.Result.Adapt<Response>();
    });
}

两种实现均通过了异常抛出相关的单元测试：

[Fact]
public async Task Validate_Throw_Exception()
{
    _ = _client
       .Setup(x => x.Validate(It.IsAny<long>()))
       .ThrowsAsync(new Exception("Exception"));

    _ = await Assert.ThrowsAsync<Exception>(() => _manager.ValidateCall(1));
}

1. 两种实现的差异是什么？ #

差异核心在于异常触发时机和异步流的处理逻辑：

• 第一种实现：异常在ContinueWith的回调内部触发。原任务执行失败后，ContinueWith会强制执行回调逻辑，在回调里调用ValidateInnerException()时才抛出内部异常，随后通过.Result同步阻塞获取任务结果，这会占用当前线程直到结果返回。
• 第二种实现：异常在原任务执行失败后立即触发。ValidateInnerException()直接挂载在原任务之后，一旦原任务失败就会立刻抛出异常，后续的ContinueWith只会在原任务成功时才会执行，完全遵循异步任务链的处理逻辑。

2. 为何Sonar会将第一种实现标记为代码异味？ #

Sonar标记的核心原因是这种写法存在死锁风险、违背异步编程最佳实践：

• 同步阻塞引发死锁：在ContinueWith回调中调用.Result，如果当前线程处于同步上下文（比如ASP.NET请求上下文、UI线程），.Result会阻塞线程等待任务完成，而任务可能需要等待当前上下文释放，最终导致死锁。
• 异常处理逻辑不合理：第一种实现中，无论原任务成功还是失败，ContinueWith都会执行回调，失败时在回调内同步抛出异常，破坏了Task异步编程中“失败任务直接传递异常”的设计原则，增加了不必要的同步操作。
• 代码可读性差：异常处理被嵌套在回调内部，异步流的逻辑不够直观，后续维护时需要额外理解嵌套的异常处理逻辑，提升了维护成本。

内容的提问来源于stack exchange，提问作者Eduardo Isaac Ballesteros