异常与错误处理优化：避免异常开销、错误码 vs 异常、断言使用

错误处理这事儿，说实话，是很多C语言开发者容易忽视的角落。我早年带团队时，见过太多项目因为错误处理写得随意，最后线上排查问题查到崩溃。今天咱们就聊聊，怎么把错误处理写得既高效又优雅。

错误码 vs 异常：C语言的选择题

C语言没有内置的异常机制，这其实是个好事。为什么？因为异常在C++里是有运行时开销的——栈展开、对象析构、异常表查找，这些都会拖慢程序。我曾在嵌入式项目里测过，一个简单的try-catch块能让函数调用开销增加30%以上。

所以，C语言的主流做法就是错误码。但错误码也有讲究，不是随便返回个-1就完事了。

举个例子，一个查找函数返回索引，那-1就可以表示没找到。但如果函数返回的是指针，NULL就是天然的错误标记。我习惯的做法是：

// 好的做法：用返回值表示状态，用输出参数返回结果
int find_user(int id, User *out_user) {
    if (id <= 0) return ERR_INVALID_ID;
    // ... 查找逻辑
    if (not_found) return ERR_NOT_FOUND;
    *out_user = found_user;
    return SUCCESS;
}

// 调用方
User user;
int ret = find_user(42, &user);
if (ret != SUCCESS) {
    // 处理错误
}

这种模式的好处是，调用方一眼就能看出「哦，这个函数可能会失败」。不像某些API，返回值是正数表示成功，负数表示错误，零表示特殊情况——你想想看，这谁记得住？

避免异常开销：C语言里的「伪异常」陷阱

有些C语言开发者会用setjmp/longjmp来模拟异常处理。嗯，这里我要泼盆冷水：千万别这么干。

setjmp/longjmp会跳过栈上的局部变量析构（虽然C没有析构函数，但资源释放是个大问题），而且它的性能开销也不小。我曾在项目中见过有人用这玩意儿做错误跳转，结果内存泄漏查了三天。

那正确的做法是什么？说白了就是：逐层返回，逐层处理。每个函数只处理自己能处理的错误，处理不了的往上抛。但注意，不要层层包装错误码，那样反而增加开销。

// 不推荐：层层包装
int read_config() {
    int fd = open_file();
    if (fd < 0) return ERR_OPEN_FAILED;
    int ret = parse_file(fd);
    if (ret < 0) return ERR_PARSE_FAILED;
    // ...
}

// 推荐：直接返回，调用方统一处理
int read_config() {
    int fd = open_file();
    if (fd < 0) return fd;  // 直接返回open的错误码
    return parse_file(fd);    // 直接返回parse的错误码
}

这样做的性能优势很明显：少了一层错误码转换，CPU缓存也利用得更好。我在性能调优时，经常看到这种「过度包装」导致的微秒级延迟，积少成多就成了大问题。

断言使用：调试时的利器，发布时的隐患

断言（assert）是个好东西，但用不好就是定时炸弹。我见过有人把断言当错误处理用，结果发布版本里断言被禁用了，程序直接跑飞。

我的原则很简单：断言只检查「不应该发生」的情况，错误码处理「可能发生」的情况。

场景	使用断言	使用错误码
函数参数为NULL（内部函数）	✅ 断言	❌
用户输入校验	❌	✅ 错误码
数组索引越界	✅ 断言（调试期）	✅ 边界检查（发布期）
文件打开失败	❌	✅ 错误码

举个例子，我写内部工具函数时，会这样用断言：

void sort_array(int *arr, size_t len) {
    assert(arr != NULL);      // 内部调用，传NULL是代码bug
    assert(len > 0);          // 空数组不应该出现
    // ... 排序逻辑
}

// 而对外API，则用错误码
int sort_array_safe(int *arr, size_t len) {
    if (arr == NULL) return ERR_NULL_POINTER;
    if (len == 0) return ERR_EMPTY_ARRAY;
    // ... 排序逻辑
    return SUCCESS;
}

这样，调试时断言能帮你快速定位bug，发布时错误码又能保证程序不会崩溃。两全其美。

错误处理的性能优化：少即是多

错误处理代码本身也是有开销的。每次函数调用都要检查返回值，每次错误分支都要执行跳转。那怎么优化？

我的经验是：把错误处理代码从热路径中移出去。说白了，就是让正常路径尽量笔直，错误处理靠边站。

// 不推荐：错误处理混在正常逻辑里
int process_data(Data *d) {
    if (validate(d) != SUCCESS) {
        log_error("validation failed");
        return ERR_VALIDATION;
    }
    // 正常处理
    if (transform(d) != SUCCESS) {
        log_error("transform failed");
        return ERR_TRANSFORM;
    }
    // ...
}

// 推荐：错误处理集中到函数末尾
int process_data(Data *d) {
    int ret = SUCCESS;
    ret = validate(d);
    if (ret != SUCCESS) goto error_exit;
    
    ret = transform(d);
    if (ret != SUCCESS) goto error_exit;
    
    // ... 更多处理
    return SUCCESS;

error_exit:
    log_error("process_data failed: %d", ret);
    cleanup(d);
    return ret;
}

你可能会说：「goto？这不是被禁止的吗？」嗯，这里我要说句公道话：在错误处理场景下，goto是C语言最优雅的写法。Linux内核里到处都是这种模式，它让正常路径和错误路径完全分离，CPU分支预测也更准。

知识体系总览

下面这张图，是我对本章知识点的梳理。你可以把它当作一个快速参考：

这张图把三个核心知识点串起来了。你写代码时，可以对照着看看：当前场景该用错误码还是断言？错误处理代码是不是拖慢了正常路径？

实战中的取舍

最后说点实际的。错误处理没有银弹，不同场景有不同的最优解：

• 嵌入式系统：资源紧张，尽量用错误码，少用断言（因为断言失败会触发abort，可能连日志都来不及写）。我习惯在嵌入式项目里自定义一个ASSERT宏，失败时记录错误码然后重启。
• 高性能服务器：错误处理代码要极致精简，能用goto就用goto。我曾经优化过一个网关程序，把错误处理从热路径移走后，吞吐量提升了12%。
• 库开发：对外API必须用错误码，内部实现可以用断言。这样用户用起来舒服，你自己调试也方便。

嗯，错误处理这事儿，说白了就是「把正确的事做对，把错误的事处理好」。别小看这几行代码，它往往决定了你的程序在线上能跑多久不出问题。