错误码与异常处理：在编程中如何捕获和处理错误码

我记得刚转岗做后端那年，有次线上服务突然大面积报错。我盯着日志看了半小时，满屏的 Exception: 500，愣是不知道哪里出了问题。后来一位老同事告诉我——你连错误码都不看，光看异常类型有什么用？

那之后我才真正理解：错误码和异常处理从来不是二选一，而是搭档。很多人习惯一把 try-except 兜住所有异常，但真正有意义的调试信息，往往藏在错误码里。

什么是错误码？什么是异常？

先说清楚概念：

• 错误码：一个预定义的整型或字符串值，用来标识特定的错误场景。比如 HTTP 状态码 404、系统调用返回的 -1、业务错误码 10001。
• 异常：编程语言提供的结构化错误处理机制，通过抛出和捕获对象来中断正常流程。

两者的关系就像“电梯故障指示灯”和“电梯停运报警声”——指示灯告诉你具体哪里坏了（错误码），报警声只告诉你“出事了”（异常）。

为什么不能只靠异常？

拿 Python 举例：

try:
    response = requests.get("https://api.example.com/data")
except requests.exceptions.RequestException as e:
    print(f"请求失败: {e}")

这段代码捕获了所有网络异常。但如果服务器返回 403 或 500 呢？requests.get() 在非 2xx 状态下并不会抛异常，你得手动检查 response.status_code。很多新人在这里翻车。

错误码捕获的三种典型模式

不同语言和场景下，捕获错误码的方式不太一样。我总结了三种常见打法：

1. 直接检查返回值（C 风格）

int ret = read_file("config.ini", buffer, sizeof(buffer));
if (ret < 0) {
    // 根据 errno 或自定义码判断
    switch(ret) {
        case -EACCES: // 权限不足
        case -ENOENT: // 文件不存在
    }
}

这种模式在底层系统编程里非常普遍。错误码直接作为函数返回值，清晰但容易遗漏检查——很多人忘了判断返回值。

2. 异常+错误码混合（Java/Python 推荐）

// Java 示例
public class BusinessException extends RuntimeException {
    private int errorCode;
    private String message;

    public BusinessException(int errorCode, String message) {
        super(message);
        this.errorCode = errorCode;
    }

    public int getErrorCode() { return errorCode; }
}

// 使用
try {
    processOrder(order);
} catch (BusinessException e) {
    if (e.getErrorCode() == 1001) {
        // 库存不足
        notifyWarehouse();
    } else if (e.getErrorCode() == 1002) {
        // 订单重复
        deduplicate();
    }
}

我建议每个业务模块都定义一套错误码枚举，异常里带上码，上层统一处理。这样日志里既有异常栈，又有精确的码值。

3. 结果对象模式（Go / Rust 风格）

type Result struct {
    Code    int
    Message string
    Data    interface{}
}

func CreateUser(name string) Result {
    if name == "" {
        return Result{Code: 40001, Message: "用户名不能为空"}
    }
    // 正常处理
    return Result{Code: 0, Data: user}
}

这种模式把错误码当作正常返回的一部分，强迫调用方处理。我个人认为这是最不容易漏掉错误码的做法，但也最容易写出满屏的 if result.Code != 0——这需要代码规范来配合。

错误码与异常处理的核心关系

为了更直观地对比，我把不同关系类型整理成表：

关系类型	描述	典型场景	我的建议
替代关系	只用错误码，不用异常	C 系统调用、嵌入式	适合性能敏感场景，但容易遗漏检查
补充关系	异常携带错误码一起抛出	Java/Python 业务系统	最推荐，兼顾追踪精度与代码可读性
并行关系	错误码用于预期错误，异常用于非预期错误	网络请求、文件IO	需要约定好分界线，否则容易混用
转换关系	把底层错误码映射为上层异常	第三方 SDK 封装	避免底层码泄露，统一对外接口

避坑指南：我踩过的三个坑

1. 错误码被异常吞掉
   我曾经在一个微服务里看到这样的代码：

   try:
       result = call_service()
   except Exception:
       return {"code": -1, "msg": "服务异常"}

   结果永远返回 -1，根本不知道什么错。应该把原始错误码带出来。
2. 错误码定义不统一
   同一个项目里，有的模块用正数表示成功，有的用 0 表示成功，还有的用字符串“OK”。这种混乱会让你在排查时看花眼。我建议全系统统一：0 成功，负数系统错误，正数业务错误。
3. 异常和错误码重复处理
   有人会在 catch 块里再次检查错误码，也在外部 if-else 里判断。这叫“双重认证”，徒增代码量。选一种方式后，保持一致。

一个完整的处理流程

下面这张图展示了从代码执行到最终决策的完整链条：

这个流程的核心思想是：先捕获，再判断，最后做差异化处理。你看，我把错误码捕获放在了异常之前——因为很多场景下，错误码比异常更早暴露问题。

日常开发中的实操要点

• 定义错误码时留出分类范围：比如 1-999 是系统级错误，1000-9999 是业务级错误，这样在日志里一眼就能区分严重程度。
• 使用枚举而非魔数：Python 里的 IntEnum，Java 的 enum，避免到处写死数字。
• 日志里同时打印码值和上下文：比如 order_id=123, error_code=1001, msg="库存不足"。光有码没有参数，排查时很痛苦。
• 测试边界错误码：很多人只测正常路径，忘记测错误码返回时的行为。我建议每个接口都写一个“错误码全覆盖”的测试用例。