C++如何自定义异常类-C++-PHP中文网

自定义C++异常类需继承std::exception或其派生类，重写const noexcept override的what()方法，提供具体错误信息，并通过构造函数传递错误详情，实现语义清晰、可分类处理的异常体系。

c++如何自定义异常类

在C++中自定义异常类，核心思路是基于现有的标准异常体系进行扩展。最直接的方式就是继承

std::exception

登录后复制

或其派生类，然后重写

what()

登录后复制

方法，以提供更具体、更有意义的错误描述。这不仅能让你的错误信息更清晰，还能让你在捕获异常时，能够区分不同类型的错误，进行更精细化的处理。

解决方案

要自定义C++异常类，你通常会遵循以下模式：

选择基类： 大多数情况下，你会选择继承
```
std::exception
```
登录后复制
。如果你想区分逻辑错误（如无效参数）和运行时错误（如文件读取失败），也可以考虑继承
```
std::logic_error
```
登录后复制
或
```
std::runtime_error
```
登录后复制
。
重写
what()
登录后复制
方法：这是最关键的一步。
```
what()
```
登录后复制
方法应该返回一个
```
const char*
```
登录后复制
，描述异常的性质。这个方法必须是
```
const
```
登录后复制
和
```
noexcept
```
登录后复制
的，并且在C++11及以后，最好加上
```
override
```
登录后复制
关键字。
构造函数： 设计一个或多个构造函数来接收错误信息。这些信息可以是字符串、错误码，或者其他任何你认为有助于描述异常的数据。将这些信息存储在类的私有成员中，供
```
what()
```
登录后复制
方法使用。

这是一个简单的自定义异常类示例：

#include <iostream>
#include <string>
#include <stdexcept> // 包含std::exception及其派生类

// 自定义异常类：MyCustomError
class MyCustomError : public std::runtime_error {
public:
    // 构造函数，接收一个字符串作为错误消息
    explicit MyCustomError(const std::string& message)
        : std::runtime_error(message), // 调用基类的构造函数
          customMessage(message) {}

    // 另一个构造函数，可以接收错误码和消息
    MyCustomError(int errorCode, const std::string& message)
        : std::runtime_error("Error Code: " + std::to_string(errorCode) + " - " + message),
          customErrorCode(errorCode),
          customMessage(message) {}

    // 重写what()方法，返回自定义的错误描述
    // 必须是const noexcept override
    const char* what() const noexcept override {
        // 返回存储的错误消息的C风格字符串
        // 注意：这里我们直接返回customMessage.c_str()，
        // 确保customMessage的生命周期长于what()的调用
        return customMessage.c_str();
    }

    // 可以添加额外的成员函数来获取自定义数据
    int getErrorCode() const noexcept {
        return customErrorCode;
    }

private:
    std::string customMessage;
    int customErrorCode = 0; // 默认错误码
};

// 示例函数，可能抛出MyCustomError
void processData(int value) {
    if (value < 0) {
        throw MyCustomError(-1, "Input value cannot be negative.");
    }
    if (value == 0) {
        throw MyCustomError("Processing data failed: value is zero.");
    }
    std::cout << "Processing value: " << value << std::endl;
}

int main() {
    try {
        processData(10);
        processData(0); // 应该抛出异常
        processData(-5); // 应该抛出异常
    } catch (const MyCustomError& e) {
        std::cerr << "Caught MyCustomError: " << e.what() << std::endl;
        if (e.getErrorCode() != 0) {
            std::cerr << "Specific error code: " << e.getErrorCode() << std::endl;
        }
    } catch (const std::exception& e) {
        std::cerr << "Caught std::exception: " << e.what() << std::endl;
    }
    std::cout << "Program continues after exception handling." << std::endl;

    return 0;
}

登录后复制

在这个例子中，

MyCustomError

登录后复制

继承自

std::runtime_error

登录后复制

，并提供了两个构造函数，一个只接收消息，另一个接收错误码和消息。

what()

登录后复制

方法返回我们存储的

customMessage

登录后复制

。

立即学习“C++免费学习笔记（深入）”；

为什么我们需要自定义C++异常？

这其实是个很实际的问题。

std::exception

登录后复制

或者像

std::runtime_error

登录后复制

这样的标准异常，虽然能告诉你“出错了”，但往往过于笼统。想象一下，你的程序因为文件读写失败而崩溃，如果只得到一个

std::runtime_error

登录后复制

，你可能还需要去翻日志，甚至调试代码才能知道具体是哪个文件、哪个操作出了问题。

自定义异常的价值在于：

语义清晰度： 你可以定义
```
FileNotFoundException
```
登录后复制
、
```
NetworkConnectionFailedException
```
登录后复制
、
```
InvalidConfigurationException
```
登录后复制
等，一眼就能看出问题所在，这比一个泛泛的“运行时错误”要有用得多。
携带额外信息： 标准异常通常只能带一个字符串消息。但实际场景中，我们可能需要更多上下文信息：错误码、文件名、行号、导致错误的具体参数值等等。自定义异常类可以有自己的成员变量来存储这些数据，方便在捕获时获取和处理。
错误分类与精细化处理： 当你有了不同类型的自定义异常，就可以在
```
catch
```
登录后复制
块中针对性地处理。比如，
```
catch (FileNotFoundException& e)
```
登录后复制
可以尝试创建文件或提示用户；
```
catch (NetworkConnectionFailedException& e)
```
登录后复制
可以尝试重连或切换备用服务器。
提高代码可读性和可维护性： 异常类型本身就能作为一种文档，清晰地表达函数可能抛出的错误类型。这使得代码更易于理解和维护。
业务逻辑的体现： 在复杂的业务系统中，你可能需要定义符合业务概念的异常，比如
```
OrderNotFoundException
```
登录后复制
或
```
InsufficientFundsException
```
登录后复制
，这让错误处理更贴近业务需求。

在我看来，自定义异常是构建健壮、可维护的大型C++应用不可或缺的一部分。它将错误处理从简单的“出错了”提升到了“具体出了什么错，在哪里出的错，我该怎么处理”的层次。

自定义异常类时有哪些关键设计考量？

设计一个好的自定义异常类并非只是简单地继承和重写

what()

登录后复制

那么简单，这里面有不少值得推敲的地方，我个人在实践中也踩过一些坑。

基类的选择：
- std::exception
  登录后复制
  ：最通用的基类，如果你不确定异常的分类，或者想定义一个所有自定义异常的顶级基类，它是个不错的选择。
- std::logic_error
  登录后复制
  ：适用于程序逻辑错误，例如无效参数、前置条件不满足等。这类错误通常是可以通过编程修复的。
- std::runtime_error
  登录后复制
  ：适用于运行时错误，例如文件I/O错误、网络通信失败、内存不足等。这类错误通常是程序外部因素导致的，难以在编译时预见。
- 继承层次： 考虑建立一个异常继承体系。例如，你可以有一个
```
MyProjectBaseException
```
  登录后复制
  继承自
```
std::runtime_error
```
  登录后复制
  ，然后所有项目内的具体异常（如
```
MyProject::DatabaseError
```
  登录后复制
  ,
```
MyProject::NetworkError
```
  登录后复制
  ）都继承自
```
MyProjectBaseException
```
  登录后复制
  。这样可以在顶层捕获所有项目异常，或在更低层捕获特定类型的异常。
```
what()
```
登录后复制
方法的实现：
- 返回值的生命周期：
```
what()
```
  登录后复制
  返回的是
```
const char*
```
  登录后复制
  ，这个字符串的生命周期必须在异常对象本身存在期间有效。最常见且安全的方式是将错误消息存储为
```
std::string
```
  登录后复制
  成员，然后返回
```
std::string::c_str()
```
  登录后复制
  。绝对不要返回局部变量的地址或指向临时对象的指针。
- noexcept
  登录后复制
  ：
```
what()
```
  登录后复制
  方法应该声明为
```
noexcept
```
  登录后复制
  。设想一下，如果
```
what()
```
  登录后复制
  在尝试获取错误描述时又抛出了异常，那将是灾难性的，因为我们正在报告一个错误，不希望在报告过程中引入新的错误。
- 描述性： 返回的字符串应该足够描述性，能帮助开发者快速定位问题。
构造函数与额外数据：

通义视频
通义万相AI视频生成工具

70

查看详情
- 灵活性： 提供多种构造函数重载，以适应不同的错误场景。例如，一个只接受消息的，一个接受错误码和消息的，一个接受文件名和行号的。
- 数据存储： 考虑异常类需要携带哪些额外信息。除了消息，可能还需要错误码（
```
int
```
  登录后复制
  或
```
enum
```
  登录后复制
  ）、文件名（
```
std::string
```
  登录后复制
  ）、函数名（
```
std::string
```
  登录后复制
  ）、时间戳等。这些数据应作为异常类的私有成员存储。
- const
  登录后复制
  成员：一旦异常被抛出，其携带的数据通常不应再被修改。所以，将这些额外数据设计为
```
const
```
  登录后复制
  成员，并通过
```
const
```
  登录后复制
  成员函数获取，是个好习惯。
拷贝语义：
- 异常对象在
```
throw
```
  登录后复制
  和
```
catch
```
  登录后复制
  之间会被拷贝。C++标准要求异常类型是可拷贝的（或可移动的）。通常情况下，让编译器自动生成默认的拷贝构造函数和拷贝赋值运算符就足够了，除非你有非常特殊的资源管理需求。如果你的异常类包含复杂的资源（比如文件句柄），你需要确保拷贝语义是正确的，或者考虑使用智能指针。
异常安全：
- 确保异常类本身的构造和析构过程不会抛出异常。如果异常的构造函数本身就可能失败，那整个异常处理机制就变得不可靠了。

这些设计上的考量，都是为了让自定义异常在实际应用中更健壮、更易用、更具诊断性。

如何在实际项目中有效地使用自定义异常？

在实际项目中，光是定义好异常类还不够，如何有效地使用它们，才是提升代码质量和可维护性的关键。

建立清晰的异常层次结构：
- 不要一下子定义几十个平级的异常类。从一个顶层的项目基类异常开始（例如
```
MyProject::Exception
```
  登录后复制
  ），然后根据功能模块或错误类型进行细分。比如，
```
MyProject::Database::Exception
```
  登录后复制
  、
```
MyProject::Network::Exception
```
  登录后复制
  、
```
MyProject::File::Exception
```
  登录后复制
  等。
- 这种层次结构允许你在不同的
```
catch
```
  登录后复制
  块中，既可以捕获所有项目异常（
```
catch (const MyProject::Exception& e)
```
  登录后复制
  ），也可以只捕获特定模块的异常（
```
catch (const MyProject::Database::Exception& e)
```
  登录后复制
  ）。
明确异常的抛出时机：
- 当函数无法完成其承诺的功能时： 这是抛出异常最主要的场景。如果一个函数被设计为返回某个结果，但由于某种不可恢复的错误无法生成这个结果，就应该抛出异常。
- 避免将异常用于常规控制流： 异常处理有性能开销，并且会打乱正常的程序流。不要用异常来处理预期内的、可以通过返回码或布尔值处理的“错误”情况。例如，检查用户输入是否为空，通常用
```
if
```
  登录后复制
  语句就足够了，而不是抛出异常。
- 只在不可恢复或需要立即终止操作时： 如果一个错误是局部可恢复的，比如尝试重新连接网络，那么在内部处理掉可能更好。只有当这个错误意味着当前操作无法继续，且需要向上传播时，才抛出异常。
合理的异常捕获策略：
- 在能够处理错误或记录错误的地方捕获： 不要层层传递异常而不做任何处理。在能够根据异常类型采取补救措施，或者至少能完整记录异常信息的地方，就应该捕获它。
- 避免“吞噬”异常： 不要捕获异常后不做任何处理就结束，这会掩盖问题。如果不能处理，至少要记录下来，或者重新抛出（
```
throw;
```
  登录后复制
  ）。
- 异常翻译： 有时，底层库抛出的异常可能过于底层或不符合你的业务逻辑。你可以在捕获这些底层异常后，将其“翻译”成更符合你项目语义的自定义异常，然后重新抛出。这能保持异常接口的一致性。
详细的日志记录：
- 当捕获到异常时，务必记录下尽可能详细的信息。这包括：异常类型、
```
what()
```
  登录后复制
  返回的消息、自定义的错误码、文件名、行号、堆栈追踪（如果可用），以及导致异常发生的上下文数据。
- 高质量的异常日志是调试和解决生产环境问题的生命线。
资源管理（RAII）：
- C++异常处理的一个重要伙伴是RAII（Resource Acquisition Is Initialization）。确保所有资源（内存、文件句柄、锁等）都通过RAII封装，这样即使在异常发生时，资源也能被正确释放，避免内存泄漏或资源泄漏。