在c++++中，自定义异常错误信息的推荐做法是继承std::exception并重载what()方法。1. 创建一个继承自std::exception的类，并添加用于存储错误信息的std::string成员变量；2. 在构造函数中接收错误信息字符串并初始化该成员变量；3. 重写what()方法，返回该成员变量的c_str()，确保指针生命周期有效；4. 可选地，为异常类添加额外上下文信息（如文件名、行号、错误码）并在构造函数中初始化；5. 可选择在what()中整合上下文信息或提供独立getter方法以支持结构化访问。这种方式不仅保持与标准异常处理机制兼容，还提升了错误信息的可读性和程序对异常的精细控制能力。
在C++中，要自定义异常的错误信息，最直接且推荐的做法是继承自
std::exception
基类，然后重载其虚函数
what()
。这个方法允许你提供一个描述性的C风格字符串，解释异常发生的原因，并且能与C++标准库的异常处理机制无缝集成。
解决方案
自定义C++异常并重载
what()
方法，核心在于创建一个继承自
std::exception
的类。在这个类中，你可以定义自己的构造函数来接收一个错误信息字符串，并将其存储为类的成员。然后，重写
what()
方法，让它返回这个存储的错误信息。
以下是一个基本的实现思路：
立即学习“C++免费学习笔记（深入）”；
#include #include #include #include // For std::runtime_error example// 自定义异常类class MyCustomException : public std::exception {private: std::string message_; // 存储具体的错误信息public: // 构造函数，接收错误信息 explicit MyCustomException(const std::string& msg) : message_(msg) {} // 重载what()方法，返回错误信息 // 注意：noexcept是C++11引入的，表示该函数不会抛出异常 // 返回的const char* 必须在异常对象的生命周期内有效 const char* what() const noexcept override { return message_.c_str(); } // 也可以添加其他方法来获取更详细的上下文信息 // 例如：int getErrorCode() const;};// 示例函数，可能抛出自定义异常void process_data(int value) { if (value < 0) { // 抛出带有特定错误信息的自定义异常 throw MyCustomException("输入值不能为负数: " + std::to_string(value)); } // 模拟其他处理... std::cout << "数据处理成功: " << value << std::endl;}int main() { try { process_data(10); process_data(-5); // 这里会抛出异常 } catch (const MyCustomException& e) { // 捕获自定义异常 std::cerr << "捕获到自定义异常: " << e.what() << std::endl; } catch (const std::exception& e) { // 捕获其他标准异常 std::cerr << "捕获到标准异常: " << e.what() << std::endl; } catch (...) { // 捕获所有其他未知异常 std::cerr << "捕获到未知异常" << std::endl; } std::cout << "程序继续执行..." << std::endl; return 0;}
在这个例子中，
MyCustomException
类通过构造函数接收一个
std::string
，并将其保存。
what()
方法则返回这个字符串的C风格表示。这样，当异常被捕获时，我们就可以通过
e.what()
获取到具体的、自定义的错误描述。
为什么不直接抛出
std::string
std::string
或者C风格字符串？
在我看来，直接抛出
std::string
或C风格字符串，虽然在某些极简场景下看起来方便，但从工程实践和代码可维护性角度来看，这通常不是一个好的选择。
首先，它丧失了类型信息。当你
throw std::string("Error!")
时，捕获方只能写
catch (std::string& e)
。这意味着你无法通过多态的方式捕获所有类型的异常（比如，你不能写
catch (const std::exception& e)
来统一处理），也无法区分不同类型的错误。在大型项目中，错误通常有不同的类别，比如文件操作错误、网络错误、逻辑错误等，通过自定义异常类型可以清晰地分类和处理这些问题。
其次，
std::exception
提供了一个标准的接口
what()
。如果你遵守这个约定，那么无论你的具体异常类型是什么，只要它继承自
std::exception
，任何捕获
std::exception
的地方都能通过
e.what()
获取到一致的错误描述。这极大地提高了代码的通用性和可读性。想象一下，如果每个模块都抛出不同类型（
std::string
、
char*
、自定义结构体）的错误，异常处理代码会变得非常混乱和难以维护。
最后，内存管理也是一个考量。抛出
std::string
通常没问题，因为
std::string
本身是RAII（资源获取即初始化）的，会妥善管理内存。但如果抛出C风格字符串（
char*
），你得非常小心它的生命周期。如果返回的是一个局部变量的地址，或者一个未被正确管理的动态分配内存的地址，那就会导致悬空指针或内存泄漏。
std::exception
及其派生类内部会负责好这些细节，你只需要关注错误信息的传递。
what()
what()
方法返回
const char*
的注意事项与内存管理？
what()
方法签名是
const char* what() const noexcept
。这里有几个关键点需要深入理解：
*`const char
返回类型**：这意味着
what()`返回的是一个指向常量字符数组的指针。你不能通过这个指针修改错误信息。更重要的是，这个指针所指向的内存必须在异常对象本身的生命周期内保持有效。
const
成员函数：表示
what()
是一个常量成员函数，它不会修改对象的状态。这意味着你可以在常量对象（包括被
const
引用捕获的异常对象）上调用它。
noexcept
关键字：这是一个非常重要的保证。
noexcept
表示这个函数承诺不会抛出任何异常。在异常处理过程中，如果
what()
本身又抛出了异常，那将导致程序立即终止（
std::terminate
）。因此，
what()
的实现必须是“绝对安全”的，不能有任何可能失败的操作，比如内存分配、文件IO等。
基于这些约束，最佳实践通常是：将错误信息存储在自定义异常类的一个
std::string
成员变量中。然后，在
what()
方法中，直接返回这个
std::string
的C风格字符串表示，即
message_.c_str()
。
class MyCustomException : public std::exception {private: std::string message_; // 存储错误信息public: explicit MyCustomException(const std::string& msg) : message_(msg) {} const char* what() const noexcept override { // 关键点：返回内部std::string的c_str() // std::string保证了其内部缓冲区的生命周期与std::string对象一致 return message_.c_str(); }};
这种方式确保了
what()
返回的
const char*
所指向的内存是有效的，因为它是由
message_
这个
std::string
成员变量管理的，而
message_
的生命周期与
MyCustomException
对象本身一致。当
MyCustomException
对象被销毁时，
message_
也会被销毁，其内部的内存自然也会被释放。
常见陷阱：
返回局部变量的地址：如果你在
what()
内部创建一个临时的
std::string
，然后返回它的
c_str()
，这是错误的。因为临时
std::string
在
what()
函数返回后就会被销毁，其内部缓冲区也随之无效，导致返回的指针成为悬空指针。
// 错误示例const char* what() const noexcept override { std::string temp_msg = "Error: " + message_; return temp_msg.c_str(); // temp_msg在函数返回后销毁，指针悬空}
返回字面量字符串（不带拷贝）：虽然字面量字符串生命周期是静态的，但如果你想在其中嵌入变量信息，就需要动态构造，那又回到了第一个陷阱。
// 这种简单返回字面量是安全的，但无法自定义内容const char* what() const noexcept override { return "Generic error.";}
如何在自定义异常中包含更多上下文信息？
仅仅一个简单的错误信息字符串，在很多复杂的场景下可能远远不够。当异常发生时，我们往往需要知道更多上下文信息来定位问题，比如：哪个文件出了问题？哪一行代码？具体的错误码是什么？操作的用户是谁？时间戳是多少？
为了在自定义异常中包含这些更丰富的上下文信息，我们可以为异常类添加额外的成员变量，并在构造函数中接收这些信息。然后，我们可以选择几种方式来暴露这些信息：
在
what()
方法中整合所有信息：这是最直接的方式。你可以在
what()
的实现中，将所有相关的上下文信息拼接成一个更长的、更详细的错误字符串。
#include #include #include #include // 用于字符串拼接class FileOperationException : public std::exception {private: std::string message_; std::string filename_; int line_number_; int error_code_; // 比如系统错误码public: FileOperationException(const std::string& msg, const std::string& filename, int line, int err_code) : message_(msg), filename_(filename), line_number_(line), error_code_(err_code) {} const char* what() const noexcept override { std::ostringstream oss; oss << "文件操作错误: " << message_ << " (文件: " << filename_ << ", 行: " << line_number_ << ", 错误码: " << error_code_ << ")"; // 注意：这里需要将拼接后的字符串存储起来，不能直接返回临时对象的c_str() // 最佳实践是，让message_存储完整的拼接字符串 // 为了演示，这里假设message_已经包含了所有信息 return message_.c_str(); // 假设message_在构造时就已拼接好 } // 为了避免what()内部拼接导致的问题，通常会在构造函数或一个内部辅助函数中完成拼接 // 或者，更好的方法是提供getter，让外部按需获取详细信息 // 这里只是为了演示在what()中包含更多信息的概念，实际代码中message_应该在构造函数中完成拼接};// 改进后的FileOperationException，在构造函数中拼接what()信息class ImprovedFileOperationException : public std::exception {private: std::string full_message_; // 存储what()的完整信息 std::string filename_; int line_number_; int error_code_; // 辅助函数，用于构建完整的错误信息 std::string build_full_message(const std::string& msg, const std::string& filename, int line, int err_code) { std::ostringstream oss; oss << "文件操作错误: " << msg << " (文件: " << filename << ", 行: " << line << ", 错误码: " << err_code << ")"; return oss.str(); }public: ImprovedFileOperationException(const std::string& msg, const std::string& filename, int line, int err_code) : full_message_(build_full_message(msg, filename, line, err_code)), filename_(filename), line_number_(line), error_code_(err_code) {} const char* what() const noexcept override { return full_message_.c_str(); } // 提供独立的getter方法，让捕获者可以结构化地访问这些信息 const std::string& getFilename() const { return filename_; } int getLineNumber() const { return line_number_; } int getErrorCode() const { return error_code_; }};void read_config(const std::string& path) { // 模拟文件读取失败 if (path == "invalid.conf") { throw ImprovedFileOperationException("无法打开配置文件", path, __LINE__, 1001); } std::cout << "成功读取配置文件: " << path << std::endl;}int main_context_info() { try { read_config("valid.conf"); read_config("invalid.conf"); } catch (const ImprovedFileOperationException& e) { std::cerr << "捕获到文件操作异常: " << e.what() << std::endl; std::cerr << "详细信息 - 文件: " << e.getFilename() << ", 行: " << e.getLineNumber() << ", 错误码: " << e.getErrorCode() << std::endl; } catch (const std::exception& e) { std::cerr << "捕获到标准异常: " << e.what() << std::endl; } return 0;}
提供独立的Getter方法：这是我个人更倾向的方式。虽然
what()
提供了一个通用的字符串描述，但在程序中，你可能需要根据错误码来做分支判断，或者根据文件名来记录日志。仅仅解析
what()
返回的字符串是低效且容易出错的。因此，为每个上下文信息提供独立的getter方法，可以让捕获者以结构化的方式访问这些数据，而不是依赖字符串解析。
在上面的
ImprovedFileOperationException
示例中，我就同时提供了
what()
方法返回一个详细的字符串，也提供了
getFilename()
、
getLineNumber()
、
getErrorCode()
等getter方法。这样，无论是人类阅读还是程序逻辑判断，都能获得所需的信息。
选择哪种方式取决于你的需求。如果只是为了日志记录或给用户看，
what()
中包含所有信息就足够了。但如果你的程序需要根据异常的特定属性进行更细粒度的处理，那么提供独立的getter方法会是更好的选择。
以上就是如何自定义C++异常的错误信息 重载what()方法最佳实践的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1470802.html
微信扫一扫 
支付宝扫一扫 
