C++异常处理与错误码返回结合使用（异常.返回.错误码...）

应结合使用异常和错误码，底层错误码在高层不可预期时转换为异常，高层用异常简化流程，可预期失败用错误码或std::expected，通过自定义异常、统一策略和RAII保持代码清晰。

c++异常处理与错误码返回结合使用

在C++的世界里，错误处理这事儿，总让人有点纠结。我们手头有两把利器：异常处理（Exceptions）和错误码返回（Error Codes）。它们各有千秋，也各有适用的场景。与其争论谁更优越，不如思考如何将它们巧妙地结合起来，让我们的代码既健壮又易于维护。在我看来，这并不是非此即彼的选择题，而是一门关于权衡和策略的艺术。核心观点是，将异常用于真正“异常”的、不可预期的、需要立即中断执行的情况，而将错误码用于那些可预期的、需要局部处理或重试的“正常”失败流程。

解决方案

结合使用C++异常处理和错误码返回，通常遵循一种分层或混合策略。这意味着在系统的不同抽象层级或针对不同类型的错误，采用最适合的机制。一个常见的做法是，在底层与系统API或库交互时，我们可能不得不处理它们返回的错误码（比如

errno

或COM的

HRESULT

）。这些错误码在当前层级可能只是一个状态指示，但当它们向上层传递，并被视为对当前业务逻辑而言的“不可接受”或“非预期”情况时，就应该将其转换为C++异常抛出。

具体来说，可以这样操作：

底层封装与转换：编写包装函数或类，将底层C风格API返回的错误码捕获。根据错误码的类型和严重性，决定是将其作为函数返回值的一部分（例如，返回一个
```
std::optional
```
或自定义的
```
Result
```
类型），还是将其翻译成一个具体的C++异常并抛出。
高层业务逻辑：在应用的高层业务逻辑中，主要依赖异常来处理错误。这意味着高层函数通常不需要检查大量的错误码，而是直接
```
try-catch
```
可能从底层抛出的异常。这使得业务逻辑的代码流更清晰，聚焦于“做什么”而非“如何处理各种失败”。
自定义异常类型：定义一套清晰、富有表达力的自定义异常类层次结构。这些异常类可以包含原始的错误码信息，以及更详细的上下文描述，方便调试和日志记录。
结果类型（
```
std::expected
```
或自定义
```
Result
```
）：对于那些“预期会失败”但又不想用异常中断流程的场景（例如，文件不存在、用户输入无效），可以考虑使用
```
std::expected<T, E>
```
（C++23标准，或Boost.Outcome等库）或自定义的
```
Result<T, E>
```
类型。这是一种结构化的错误码返回方式，它明确表示函数可能返回一个成功的值
```
T
```
，或者一个错误值
```
E
```
，使得错误处理变得显式且类型安全，避免了异常的开销。

什么时候应该优先使用异常处理，什么时候选择错误码？

这确实是一个需要深思熟虑的问题，没有一刀切的答案，更多的是一种哲学选择。我的个人经验告诉我，这取决于错误的“性质”和“预期性”。

优先使用异常处理的场景：

真正的异常情况：当错误发生时，程序无法继续以有意义的方式执行，或者继续执行会导致更严重的问题（比如资源耗尽、内存分配失败、无效的程序状态）。这些是“意外”事件，通常意味着程序逻辑或环境出现了问题。
构造函数失败：构造函数无法返回错误码，因此抛出异常是表示对象创建失败的唯一标准方式。
跨越多个抽象层级的错误传播：如果一个底层错误需要一直传播到高层才能被有意义地处理，异常可以避免在中间层函数签名中添加大量的错误码参数或返回值，使代码更简洁。想象一下，一个文件读取函数在底层失败了，这个错误可能需要一直冒泡到用户界面层才能提示用户。如果用错误码，每个中间函数都需要检查并传递。
违反函数前置条件：当函数的输入参数不满足其预设条件时（例如，传入空指针给一个不允许为空的函数），这通常是调用者的逻辑错误，抛出异常（如
```
std::invalid_argument
```
）可以明确指出问题。

优先选择错误码的场景：

Post AI

博客文章AI生成器

50 查看详情 Post AI

可预期的、常规的失败：当失败是业务逻辑的一部分，并且调用者需要显式地检查并处理时。例如，尝试打开一个可能不存在的文件，或者网络请求超时。这些情况并不意味着程序本身出了问题，而是外部环境或业务流程的正常反馈。
性能敏感的代码路径：异常的抛出和捕获涉及栈展开，这会有一定的性能开销。在对性能要求极高的循环或函数中，使用错误码可能更高效。
与C语言或外部API交互：许多操作系统API和C库都使用错误码（如
```
errno
```
）来指示失败。直接处理这些错误码通常更自然。
明确的成功/失败状态：当函数的主要目的是执行一个操作并返回其成功或失败状态时，错误码（或
```
std::expected
```
）能更直接地表达这一点，而无需引入异常的控制流。

将底层错误码转换为C++异常的最佳实践是什么？

将底层错误码转换为C++异常，关键在于“语义化”和“封装”。我们不希望仅仅把

errno

的值原样抛出去，而是要将其包装成对当前应用层有意义的异常。

一个行之有效的方法是创建自定义异常类。这些类应该继承自

std::exception

（或其派生类，如

std::runtime_error

或

std::logic_error

），并包含足够的信息来帮助诊断问题。

#include <stdexcept>
#include <string>
#include <system_error> // For std::system_error and std::error_code
#include <iostream>
#include <fstream> // For file operations
#include <vector>

// 1. 定义自定义异常类
class FileOperationException : public std::runtime_error {
public:
    // 可以存储原始错误码，方便调试
    explicit FileOperationException(const std::string& message, int errorCode = 0)
        : std::runtime_error(message), originalErrorCode_(errorCode) {}

    int getOriginalErrorCode() const { return originalErrorCode_; }

private:
    int originalErrorCode_;
};

class FileNotFoundError : public FileOperationException {
public:
    explicit FileNotFoundError(const std::string& message, int errorCode = 0)
        : FileOperationException(message, errorCode) {}
};

class PermissionDeniedError : public FileOperationException {
public:
    explicit PermissionDeniedError(const std::string& message, int errorCode = 0)
        : FileOperationException(message, errorCode) {}
};

// 2. 封装底层C风格文件操作，将errno转换为C++异常
void openAndReadFile(const std::string& filename) {
    std::ifstream file(filename);
    if (!file.is_open()) {
        // 在这里，我们通常无法直接获取errno，因为std::ifstream封装了它
        // 但如果是一个C风格的open()，我们可以这样做：
        // int fd = open(filename.c_str(), O_RDONLY);
        // if (fd == -1) {
        //     int err = errno; // 捕获原始errno
        //     if (err == ENOENT) {
        //         throw FileNotFoundError("Failed to open file: " + filename + ". File does not exist.", err);
        //     } else if (err == EACCES) {
        //         throw PermissionDeniedError("Failed to open file: " + filename + ". Permission denied.", err);
        //     } else {
        //         throw FileOperationException("Failed to open file: " + filename + ". System error code: " + std::to_string(err), err);
        //     }
        // }
        // For std::ifstream, we might infer or provide a more generic message
        throw FileOperationException("Failed to open file: " + filename + ". Check path and permissions.");
    }

    std::string line;
    while (std::getline(file, line)) {
        std::cout << line << std::endl;
    }
    // std::ifstream 在析构时会自动关闭文件，符合RAII
}

// 另一个例子：处理一个假想的返回错误码的API
enum class NetworkErrorCode {
    Success = 0,
    ConnectionRefused,
    Timeout,
    InvalidHost,
    UnknownError
};

NetworkErrorCode connectToServer(const std::string& host, int port) {
    if (host == "bad.host") return NetworkErrorCode::InvalidHost;
    if (port == 8080) return NetworkErrorCode::ConnectionRefused; // Simulate connection refused
    if (port == 9000) return NetworkErrorCode::Timeout; // Simulate timeout
    return NetworkErrorCode::Success;
}

// 封装并转换网络错误码
void establishNetworkConnection(const std::string& host, int port) {
    NetworkErrorCode ec = connectToServer(host, port);
    if (ec != NetworkErrorCode::Success) {
        std::string message = "Network connection failed to " + host + ":" + std::to_string(port) + ". ";
        switch (ec) {
            case NetworkErrorCode::ConnectionRefused:
                throw std::runtime_error(message + "Connection refused.");
            case NetworkErrorCode::Timeout:
                throw std::runtime_error(message + "Timeout occurred.");
            case NetworkErrorCode::InvalidHost:
                throw std::invalid_argument(message + "Invalid host specified.");
            case NetworkErrorCode::UnknownError:
            default:
                throw std::runtime_error(message + "Unknown network error.");
        }
    }
    std::cout << "Successfully connected to " << host << ":" << port << std::endl;
}

// 示例使用
int main() {
    std::cout << "--- File Operations ---" << std::endl;
    try {
        openAndReadFile("non_existent_file.txt");
    } catch (const FileNotFoundError& e) {
        std::cerr << "Caught FileNotFoundError: " << e.what() << " (Error code: " << e.getOriginalErrorCode() << ")" << std::endl;
    } catch (const FileOperationException& e) {
        std::cerr << "Caught FileOperationException: " << e.what() << " (Error code: " << e.getOriginalErrorCode() << ")" << std::endl;
    } catch (const std::exception& e) {
        std::cerr << "Caught general exception: " << e.what() << std::endl;
    }

    std::cout << "\n--- Network Operations ---" << std::endl;
    try {
        establishNetworkConnection("good.host", 8080); // Will simulate connection refused
    } catch (const std::invalid_argument& e) {
        std::cerr << "Caught invalid argument: " << e.what() << std::endl;
    } catch (const std::runtime_error& e) {
        std::cerr << "Caught runtime error: " << e.what() << std::endl;
    } catch (const std::exception& e) {
        std::cerr << "Caught general exception: " << e.what() << std::endl;
    }

    try {
        establishNetworkConnection("bad.host", 1234); // Will simulate invalid host
    } catch (const std::invalid_argument& e) {
        std::cerr << "Caught invalid argument: " << e.what() << std::endl;
    }

    try {
        establishNetworkConnection("good.host", 1234); // Success
    } catch (const std::exception& e) {
        std::cerr << "Caught unexpected exception: " << e.what() << std::endl;
    }

    return 0;
}

这段代码展示了如何通过自定义异常类来封装底层错误码，并在更高的抽象层级抛出具有语义的异常。这样，上层调用者可以根据具体的异常类型进行更精细的错误处理，而不是仅仅看到一个数字。

如何在异常和错误码并存的系统中维护代码清晰性和可读性？

在一个同时使用异常和错误码的复杂系统中，保持代码的清晰性和可读性确实是个挑战。如果处理不当，代码会变得混乱不堪，错误处理逻辑也难以追踪。我的经验告诉我，关键在于一致性、明确的策略和良好的文档。

制定并遵循统一的错误处理策略：这是最重要的一点。团队内部必须就“何时使用异常，何时使用错误码”达成共识，并严格执行。例如，可以规定：所有API调用失败，如果导致程序无法继续执行，则抛出异常；如果只是业务逻辑上的“非成功”状态，则返回
```
Result
```
类型或错误码。
清晰的函数签名和文档：
- 对于抛出异常的函数：在函数注释中明确指出可能抛出的异常类型及其条件。C++20引入的
```
[[nodiscard]]
```
  属性可以提醒调用者检查返回值，但对于异常，主要是靠文档和
```
noexcept
```
  关键字（如果函数确定不抛出）。
- 对于返回错误码或
```
Result
```
  类型的函数：明确说明返回值的含义，包括成功时的值和各种错误码的定义。使用
```
enum class
```
  来定义错误码，可以避免命名冲突并提高类型安全性。
```
[[nodiscard]]
```
  在这里尤为重要，它能强制调用者处理返回值，避免静默失败。
避免在同一函数中混淆主要错误处理机制：一个函数的主要失败路径应该要么通过异常，要么通过错误码来表示。如果一个函数既能抛出异常又能返回错误码来表示同一种类型的失败，那就会让人非常困惑。当然，一个函数可能因为内存不足而抛出
```
std::bad_alloc
```
（异常），同时因为文件不存在而返回
```
ErrorCode::FileNotFound
```
（错误码），这是可以接受的，因为它们代表不同性质的失败。
封装底层细节：尽量将底层错误码的转换逻辑封装在模块的内部，不让它们泄露到高层。高层代码应该只关心高层语义的异常或结果。
使用RAII（Resource Acquisition Is Initialization）：无论使用异常还是错误码，RAII都是确保资源正确管理（如文件句柄、锁、内存）的基石。当异常发生时，RAII对象会自动析构，从而释放资源，防止资源泄露。
日志记录：无论采用哪种错误处理机制，详细的日志记录都是不可或缺的。在捕获异常或处理错误码时，记录下关键信息、堆栈轨迹（如果可用）和原始错误码，对于问题排查至关重要。

通过这些实践，我们可以在一个混合的错误处理体系中，构建出既高效又易于理解和维护的代码。关键在于有意识地设计，而不是随意地将两者混用。

以上就是C++异常处理与错误码返回结合使用的详细内容，更多请关注知识资源分享宝库其它相关文章！

相关标签： go c语言操作系统 ai c++ ios switch api调用 red c语言 Resource 封装构造函数 try catch Error enum errno 循环指针继承栈堆 class 空指针对象事件大家都在看： Golang的包管理机制如何运作介绍go mod的依赖管理方式 C++和Go之间有哪些区别？ C++如何减少内存分配与释放次数 C++模板元编程基础与应用 C++循环优化与算法选择技巧

C++异常处理与错误码返回结合使用（异常.返回.错误码...）

最近发表

标签列表

C++异常处理与错误码返回结合使用（异常.返回.错误码...）

相关阅读

C++结构体与类继承的兼容性分析（兼容性.继承.结构.分析...）

C++lambda表达式捕获引用与值的区别（表达式.捕获.区别.引用.lambda...）

C++内存模型与锁粒度优化策略（粒度.模型.内存.优化.策略...）