C++ 程序在 Linux 上如何进行错误处理

时间：2026-08-25 | 作者：宇宙开黑者 | 阅读：0

前言

在 Linux 环境里写 C++，错误处理往往不是“会不会写”的问题，而是“该用哪一种”更关键。返回值、异常、errno 和现代错误码封装各有边界，本文按实际开发中最常见的场景拆开讲清楚，帮助你判断什么时候该追求简单直接，什么时候该把错误传播和系统信息保留下来。

返回错误码：最直接，也最适合轻量流程

最传统的办法，就是让函数用返回值表达执行结果：成功返回 0，失败返回非零值。这种方式从 C 时代延续到现在，在很多底层程序、命令行工具和历史较长的库里仍然很常见。

它的优点很明确：

实现简单，调用约定清楚；
不依赖异常机制，适合轻量程序或受限环境；
调用方可以明确决定每一步失败后怎么处理。

但它也有明显限制。只要调用链一长，错误检查代码就会迅速增多，正常逻辑和异常路径容易混在一起；如果开发者忘记检查返回值，错误就可能被悄悄吞掉。

下面这类写法就是典型例子：

int main() {
    int result = some_function();
    if (result != 0) {
        std::cerr << "Error occurred in some_function()" << std::endl;
        return result;
    }
    return 0;
}

如果程序本身结构简单、函数层级不深，这种方式足够直接，也容易排查问题。对很多小工具来说，它依然是成本最低的选择。

异常处理：把错误路径从正常逻辑里分离出来

C++ 更有代表性的方案，是使用 try、catch 和 throw 做异常处理。它的核心思路是：函数在无法自行处理错误时，不必层层返回状态码，而是抛出异常，由更高层统一接住并处理。

对比返回错误码、异常处理、系统错误接口三种常见方案的适用边界 — **C++ 常见错误处理方案对比**把常见错误处理方案放到同一张图里，更容易看清代码复杂度、错误传播方式和典型使用位置的区别。

这种方式最大的价值，是把“正常流程”和“错误流程”拆开。代码可读性通常会更好，尤其在多层调用、对象资源管理、复杂业务逻辑里，异常比逐层传递返回值更自然。

例如下面这段代码中，some_function 遇到错误条件时会抛出 std::runtime_error，而 main 只需要在统一入口捕获：

#include 

int some_function() {
    if (/* error condition */) {
        throw std::runtime_error("An error occurred in some_function()");
    }
    return 0;
}

int main() {
    try {
        int result = some_function();
    } catch (const std::exception& e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return 1;
    }
    return 0;
}

这种写法适合几类情况：

函数调用层次较深，逐层返回错误码会让代码变得臃肿；
需要把错误集中到边界层统一记录、提示或退出；
项目本身已经采用 RAII 等现代 C++ 风格，希望错误传播更自然。

当然，异常也不是默认最优解。如果项目明确禁用异常，或者处在某些对开销、二进制体积、调用约定要求更严格的底层模块里，就不一定适合采用这一路线。关键不在于“异常更高级”，而在于它是否符合当前工程的约束。

系统接口出错时，优先看 errno 和 strerror()

一旦代码开始和 Linux 系统接口打交道，错误处理的重点就变了。文件、网络、进程这类底层操作，经常不是由你自定义函数返回业务含义上的失败，而是由系统调用或 C 标准库接口提供错误状态。

展示 Linux 系统调用失败后，从返回值判断到读取 errno 再输出错误文本的处理流程 — **系统级错误的处理链路**系统级错误最怕丢上下文，这张图把 fopen 失败后的处理顺序串起来，便于理解为什么。

这时最常见的组合就是 errno 与 strerror()。当类似 fopen 这样的操作失败时，函数本身会返回空指针或错误值，而具体失败原因则写入 errno。随后再通过 strerror(errno) 把错误码转成可读文本。

例如：

#include 
#include 
#include 

int main() {
    FILE* file = fopen("nonexistent_file.txt", "r");
    if (file == nullptr) {
        std::cerr << "Error: " << std::strerror(errno) << std::endl;
        return 1;
    }
    fclose(file);
    return 0;
}

这类方式在 Linux 下非常实用，因为它直接对应操作系统给出的失败原因。比如文件不存在、权限不足、资源忙、地址不可用等问题，通常都能通过系统错误码快速定位。

不过这里也要注意边界：errno 更适合系统级接口，不适合拿来表达通用业务逻辑。换句话说，如果是“用户输入格式不对”“配置项缺失”这类程序内部错误，硬套 errno 并不合适；但只要你在处理文件、套接字、进程控制等能力，它依旧是 Linux 世界里最基础也最可靠的一层信息来源。