C++如何自定义异常类

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

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

std::exception

或其派生类，然后重写

what()

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

解决方案

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

1. 选择基类： 大多数情况下，你会选择继承

   std::exception

   。如果你想区分逻辑错误（如无效参数）和运行时错误（如文件读取失败），也可以考虑继承

   std::logic_error

   或

   std::runtime_error

   。

2. 重写

   what()

   方法： 这是最关键的一步。

   what()

   方法应该返回一个

   const char*

   ，描述异常的性质。这个方法必须是

   const

   和

   noexcept

   的，并且在C++11及以后，最好加上

   override

   关键字。

3. 构造函数： 设计一个或多个构造函数来接收错误信息。这些信息可以是字符串、错误码，或者其他任何你认为有助于描述异常的数据。将这些信息存储在类的私有成员中，供

   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()

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

1. 基类的选择：

   • std::exception

     ： 最通用的基类，如果你不确定异常的分类，或者想定义一个所有自定义异常的顶级基类，它是个不错的选择。

   • std::logic_error

     ： 适用于程序逻辑错误，例如无效参数、前置条件不满足等。这类错误通常是可以通过编程修复的。

   • std::runtime_error

     ： 适用于运行时错误，例如文件I/O错误、网络通信失败、内存不足等。这类错误通常是程序外部因素导致的，难以在编译时预见。

   • 继承层次： 考虑建立一个异常继承体系。例如，你可以有一个

     MyProjectBaseException

     继承自

     std::runtime_error

     ，然后所有项目内的具体异常（如

     MyProject::databaseError

     ,

     MyProject::NetworkError

     ）都继承自

     MyProjectBaseException

     。这样可以在顶层捕获所有项目异常，或在更低层捕获特定类型的异常。

2. what()

   方法的实现：

   • 返回值的生命周期：

     what()

     返回的是

     const char*

     ，这个字符串的生命周期必须在异常对象本身存在期间有效。最常见且安全的方式是将错误消息存储为

     std::string

     成员，然后返回

     std::string::c_str()

     。绝对不要返回局部变量的地址或指向临时对象的指针。

   • noexcept

     ：

     what()

     方法应该声明为

     noexcept

     。设想一下，如果

     what()

     在尝试获取错误描述时又抛出了异常，那将是灾难性的，因为我们正在报告一个错误，不希望在报告过程中引入新的错误。

   • 描述性： 返回的字符串应该足够描述性，能帮助开发者快速定位问题。

3. 构造函数与额外数据：

   

   千帆AppBuilder

   百度推出的一站式的AI原生应用开发资源和工具平台，致力于实现人人都能开发自己的AI原生应用。

   90

   查看详情

   • 灵活性： 提供多种构造函数重载，以适应不同的错误场景。例如，一个只接受消息的，一个接受错误码和消息的，一个接受文件名和行号的。
   • 数据存储： 考虑异常类需要携带哪些额外信息。除了消息，可能还需要错误码（

     int

     或

     enum

     ）、文件名（

     std::string

     ）、函数名（

     std::string

     ）、时间戳等。这些数据应作为异常类的私有成员存储。

   • const

     成员： 一旦异常被抛出，其携带的数据通常不应再被修改。所以，将这些额外数据设计为

     const

     成员，并通过

     const

     成员函数获取，是个好习惯。

4. 拷贝语义：

   • 异常对象在

     throw

     和

     catch

     之间会被拷贝。C++标准要求异常类型是可拷贝的（或可移动的）。通常情况下，让编译器自动生成默认的拷贝构造函数和拷贝赋值运算符就足够了，除非你有非常特殊的资源管理需求。如果你的异常类包含复杂的资源（比如文件句柄），你需要确保拷贝语义是正确的，或者考虑使用智能指针。

5. 异常安全：

   • 确保异常类本身的构造和析构过程不会抛出异常。如果异常的构造函数本身就可能失败，那整个异常处理机制就变得不可靠了。

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

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

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

1. 建立清晰的异常层次结构：

   • 不要一下子定义几十个平级的异常类。从一个顶层的项目基类异常开始（例如

     MyProject::Exception

     ），然后根据功能模块或错误类型进行细分。比如，

     MyProject::Database::Exception

     、

     MyProject::Network::Exception

     、

     MyProject::File::Exception

     等。

   • 这种层次结构允许你在不同的

     catch

     块中，既可以捕获所有项目异常（

     catch (const MyProject::Exception& e)

     ），也可以只捕获特定模块的异常（

     catch (const MyProject::Database::Exception& e)

     ）。

2. 明确异常的抛出时机：

   • 当函数无法完成其承诺的功能时： 这是抛出异常最主要的场景。如果一个函数被设计为返回某个结果，但由于某种不可恢复的错误无法生成这个结果，就应该抛出异常。
   • 避免将异常用于常规控制流： 异常处理有性能开销，并且会打乱正常的程序流。不要用异常来处理预期内的、可以通过返回码或布尔值处理的“错误”情况。例如，检查用户输入是否为空，通常用

     if

     语句就足够了，而不是抛出异常。

   • 只在不可恢复或需要立即终止操作时： 如果一个错误是局部可恢复的，比如尝试重新连接网络，那么在内部处理掉可能更好。只有当这个错误意味着当前操作无法继续，且需要向上传播时，才抛出异常。

3. 合理的异常捕获策略：

   • 在能够处理错误或记录错误的地方捕获： 不要层层传递异常而不做任何处理。在能够根据异常类型采取补救措施，或者至少能完整记录异常信息的地方，就应该捕获它。
   • 避免“吞噬”异常： 不要捕获异常后不做任何处理就结束，这会掩盖问题。如果不能处理，至少要记录下来，或者重新抛出（

     throw;

     ）。

   • 异常翻译： 有时，底层库抛出的异常可能过于底层或不符合你的业务逻辑。你可以在捕获这些底层异常后，将其“翻译”成更符合你项目语义的自定义异常，然后重新抛出。这能保持异常接口的一致性。

4. 详细的日志记录：

   • 当捕获到异常时，务必记录下尽可能详细的信息。这包括：异常类型、

     what()

     返回的消息、自定义的错误码、文件名、行号、堆栈追踪（如果可用），以及导致异常发生的上下文数据。

   • 高质量的异常日志是调试和解决生产环境问题的生命线。

5. 资源管理（RAII）：

   • C++异常处理的一个重要伙伴是RAII（Resource Acquisition Is Initialization）。确保所有资源（内存、文件句柄、锁等）都通过RAII封装，这样即使在异常发生时，资源也能被正确释放，避免内存泄漏或资源泄漏。

总之，自定义异常是C++提供的一个强大工具，它能让你的程序在面对错误时更加优雅和健壮。但像所有强大的工具一样，它需要被正确地理解和使用，才能发挥出最大的价值。