C#异常处理边界该怎么划分

在C#项目的代码评审里，异常处理几乎是最容易引发分歧的话题之一。有人习惯在每个可能出错的地方都裹一层try-catch，有人则主张业务代码里一行try-catch都不写、全部交给全局兜底。两种做法各有拥护者，争论往往停留在“风格”层面，却很少有人把背后的职责边界讲清楚。

其实，“能处理才catch，处理不了往上抛”这句话已经点到了核心。问题不在于catch写多写少，而在于团队是否对“谁负责捕获、谁负责记录、谁负责决策”有统一认识。本文试图把这条边界划得更具体一些：以全局兜底为主干，局部只保留有明确目的的try-catch，同时把预期内的业务分支从异常机制里剥离出去。

一、到处catch的代价：异常被吞掉，问题被掩盖

最常见的反面模式，是“为了程序不崩溃”而在每个调用点包一层捕获：

try
{
    await _dbContext.SaveChangesAsync();
}
catch (Exception ex)
{
    _logger.LogError(ex, "保存失败");
}

这段代码看起来无害，日志也记了，程序也没崩。但异常消失并不等于问题解决。设想一个支付回调场景：底层持久化因为数据库死锁或锁等待超时抛出异常，被这层catch吞掉后，上层逻辑继续执行，还向外部返回了成功响应。表面上风平浪静，实际上外部支付结果与本地订单状态已经不一致，这类数据漂移的排查成本远高于一次直接崩溃。

吞异常的本质问题在于：捕获方没有能力处理，却擅自替上层做了“继续执行”的决策。catch块里只写日志、不重抛、不补偿、不改变后续流程，基本可以判定这是一层无效捕获——它唯一的作用是把一次显式失败变成一次隐式失败。

二、重复记日志：同一个错误只应记一次Error

另一个高频写法是“每层都catch、打条日志、再throw”：

catch (Exception ex)
{
    _logger.LogError(ex, "仓储层查询失败");
    throw;
}

异常确实没被吞，但仓储层、服务层、全局中间件各记一条，一次数据库闪断就能在日志里刷出三四条一模一样的Error堆栈。日志本应是排查线索，重复记录反而成了噪声，淹没了真正有价值的信息。

合理的约定是：同一个错误，只在最终负责处理它的地方记录一次Error级别日志。中间层如果确实需要补充上下文，可以附加信息后重抛（如包装成带业务标识的自定义异常），但不重复记录。全局处理器作为最后一道防线，统一记录完整堆栈与请求上下文，这才是它存在的意义。

三、完全不写局部捕获，也会踩坑

既然全局兜底这么好，业务代码里一行try-catch都不写行不行？同样会出问题，最典型的是批处理场景。

假设循环同步1000条独立数据，如果完全不捕获，第3条因为格式错误抛出异常，后面997条数据就全部中断了——而它们彼此独立，本不应互相牵连。此时合理的做法是在单条处理粒度上加捕获，把失败项记录下来继续推进：

foreach (var item in batch)
{
    try
    {
        await ProcessAsync(item);
    }
    catch (Exception ex)
    {
        _logger.LogWarning(ex, "条目 {Id} 处理失败，跳过", item.Id);
        failedItems.Add(item.Id);
    }
}

注意这里的失败语义：整个批次不要求原子性，单条失败可跳过、可重试、可人工介入。反过来，如果业务本身要求“全成功或全回滚”，那遇到异常直接中断才是正确行为。批处理该不该局部捕获，取决于失败语义，而不是代码风格。

另一个问题是上下文缺失。底层解析或计算出异常直接冒到顶层，全局中间件即便记下完整堆栈，日志里往往也没有订单号、租户ID等业务标识，很难定位是哪条数据引发的。局部捕获的价值之一，就是在异常还带着业务上下文时把它附加到日志或异常信息里。

四、把边界划成三层

综合来看，实际项目中可以把异常处理划成三块，写代码时就不必反复纠结。

第一层：预期内的业务失败，不要用异常表达。

参数解析失败、余额不足、库存不够，本质上都是可预期的业务结果，不是“异常”。参数校验交给请求管道拦截并返回400（例如使用验证库，或在Minimal API中注册内置验证支持）；业务规则不满足时，用Result<T>或错误码返回，比抛异常更清晰、更廉价，也更容易被调用方显式处理。

public Result<Order> CreateOrder(CreateOrderRequest req)
{
    if (req.Quantity <= 0)
        return Result<Order>.Fail("数量必须大于零");
    if (!_inventory.HasStock(req.ProductId, req.Quantity))
        return Result<Order>.Fail("库存不足");
    // ...
}

异常应当留给“意料之外”的情况：依赖不可用、数据损坏、违反不变量等。把可预期分支塞进异常通道，会让catch块变成if-else的替代品，既损失性能，也模糊了真正的故障信号。

第二层：局部只写有明确目的的try-catch。

所谓“有明确目的”，指捕获后要做一件具体的事：重试、降级、补偿、附加业务上下文、按条目隔离失败。如果捕获块里只是记日志然后继续，或者只是记日志然后重抛，那这层捕获大概率是多余的。判断标准很简单：删掉这个catch，行为是否有实质变化？没有就该删。

第三层：全局兜底负责最后一道防线。

全局异常处理中间件或过滤器承担三件事：统一记录一次带完整上下文的Error日志、把异常转换为对外的标准错误响应、避免进程崩溃。它不负责业务恢复，也不应该被当作“反正有兜底”而随意抛异常的借口。

五、落地建议

把这套边界落到团队协作上，可以从几条可操作的约定开始：统一日志规范，同一异常只记一次Error，中间层只附加信息不重复记录；把可预期业务失败建模为返回值而非异常；批处理显式声明失败语义，原子性要求与非原子性要求走不同路径；在代码评审中把“无处理的catch”和“只记日志再重抛”列为需要说明理由的写法。

异常处理从来不是风格问题，而是职责划分问题。全局兜底为主、局部捕获有明确目的、业务分支不走异常通道——这三条对齐之后，代码既能避免崩溃恐惧下的盲目捕获，也能避免过度依赖顶层兜底带来的上下文丢失，团队讨论也会从“你习惯哪种写法”转向“这个失败该由谁负责”。