C#异步方法Try块Return后无故跳转Catch块Return问题排查

核心根因 #

• 参数校验逻辑完全失效
  现有代码中参数判空后仅创建了ArgumentNullException实例，缺失throw关键字，异常对象创建后直接被丢弃，不会实际抛出，等于没有做参数校验。
• 调试器异步状态机映射错位造成执行流异常的错觉
  async/await语法会被编译器改写为异步状态机结构，await using、try/catch、return语句都会被拆分为多个状态片段，调试器单步执行时经常出现行号映射偏差：
  • 你看到的「命中try块return后直接跳转到catch块return、异常对象ex不存在、日志逻辑未执行」，本质是调试器将DbContext释放阶段的执行位置错误映射到了catch块内最近的return语句，实际根本没有进入catch块，自然不存在ex对象，也不会执行catch块内的日志逻辑。
  • 之前观察到的「if和else分支同时执行」也是相同的映射错位问题，实际CLR执行时不可能进入两个互斥分支。
• DbContext释放阶段的隐式异常触发调试错位
  你将await using var db声明在了try/catch结构外部，当try块内的查询完成、执行return逻辑后，会在方法退出前触发DbContext的DisposeAsync操作。如果此时出现连接释放异常、查询结果未完全消费等问题，EF Core会在释放阶段抛出异常，这个异常不在try/catch的捕获范围内，会直接打断正常返回流程，配合调试器的映射错位，就会出现你观察到的异常跳转现象。
  额外说明：EF Core的ToListAsync()方法永远不会返回null，无匹配数据时会返回空列表，因此代码中if (result != null)属于冗余判断，永远为true。

修复方案 #

1. 补全参数校验的throw关键字，正确抛出参数空异常
2. 将DbContext的await using声明移入try块内部，让DbContext使用、释放全流程的异常都能被catch块正常捕获
3. 移除冗余的result非空判断
4. 调试异步代码时建议开启VS的「仅我的代码」选项，减少编译器生成的状态机代码对调试行号的干扰

修复后的完整代码如下：

public async Task<List<ResourceModel>> GetResourcesByTypeAsync(string resourceTypeName)
{
    if(string.IsNullOrEmpty(resourceTypeName))
        throw new ArgumentNullException(nameof(resourceTypeName));

    try
    {
        await using var db = _dbFactory.CreateDbContext();
        var result = await db.ProjectResources
            .Where(x => x.ResourceType.Name == resourceTypeName)
            .AsNoTracking()
            .ToListAsync();

        return result;
    }
    catch(Exception ex)
    {
        _logger.LogCritical(ex, "查询类型为{ResourceType}的资源失败", resourceTypeName);
        return new List<ResourceModel>();
    }
}

注意：日志记录时建议直接传入异常对象ex而非仅ex.Message，否则日志系统无法记录完整堆栈信息，不利于问题排查。

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