自定义C++异常类需继承std::exception或其派生类，重写const noexcept override的what()方法，提供具体错误信息，并通过构造函数传递错误详情，实现语义清晰、可分类处理的异常体系。
在C++中自定义异常类，核心思路是基于现有的标准异常体系进行扩展。最直接的方式就是继承
std::exception
或其派生类，然后重写
what()
方法，以提供更具体、更有意义的错误描述。这不仅能让你的错误信息更清晰，还能让你在捕获异常时，能够区分不同类型的错误，进行更精细化的处理。
解决方案
要自定义C++异常类，你通常会遵循以下模式：
选择基类： 大多数情况下，你会选择继承
std::exception
。如果你想区分逻辑错误（如无效参数）和运行时错误（如文件读取失败），也可以考虑继承
std::logic_error
或
std::runtime_error
。重写
what()
方法： 这是最关键的一步。
what()
方法应该返回一个
const char*
，描述异常的性质。这个方法必须是
const
和
noexcept
的，并且在C++11及以后，最好加上
override
关键字。构造函数： 设计一个或多个构造函数来接收错误信息。这些信息可以是字符串、错误码，或者其他任何你认为有助于描述异常的数据。将这些信息存储在类的私有成员中，供
what()
方法使用。
这是一个简单的自定义异常类示例：
#include #include #include // 包含std::exception及其派生类// 自定义异常类：MyCustomErrorclass 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; // 默认错误码};// 示例函数，可能抛出MyCustomErrorvoid 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()
在尝试获取错误描述时又抛出了异常，那将是灾难性的，因为我们正在报告一个错误，不希望在报告过程中引入新的错误。描述性： 返回的字符串应该足够描述性，能帮助开发者快速定位问题。
构造函数与额外数据：
灵活性： 提供多种构造函数重载，以适应不同的错误场景。例如，一个只接受消息的，一个接受错误码和消息的，一个接受文件名和行号的。数据存储： 考虑异常类需要携带哪些额外信息。除了消息，可能还需要错误码（
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封装，这样即使在异常发生时，资源也能被正确释放，避免内存泄漏或资源泄漏。
总之，自定义异常是C++提供的一个强大工具，它能让你的程序在面对错误时更加优雅和健壮。但像所有强大的工具一样，它需要被正确地理解和使用，才能发挥出最大的价值。
以上就是C++如何自定义异常类的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1475126.html
微信扫一扫 
支付宝扫一扫 
