Question

我想知道为什么，如果是这样，有什么好处，你会创建一个异常对象来抛出异常，这些异常来自stdexcept头，例如派生自runtime_error的异常对象。我能真正找到你为什么会这样做的唯一方法是，你可以访问虚拟功能＆＃39;什么＆＃39;获取适当的错误消息。但是，您是否只是将错误消息作为参数传递给runtime_error，并访问＆＃39; what＆＃39;呢？

class divide_by_zero : public runtime_error
{
public:
    divide_by_zero()
        :runtime_error( "this is a runtime error" ) {};
}


if( ... )
{
    throw divide_by_zero();
}

与仅仅做......之类的事情有什么不同？

if( ... )
{
    throw std::runtime_error( "this is a runtime error" );
} 


try
{
    ...
}
catch( std::runtime_error& e )
{
    std::cerr << e.what()
              << std::endl;
}

Answer 1

已退休的Ninja评论说“你可以捕获派生的异常而不会捕获所有runtime_error例外。”，这是一个关键点。您的代码可能需要divide_by_zero，并希望忽略或记录它，但不希望隐藏runtime_error std::locale::locale被隐藏起来。

此外，请注意，如果您使用相同的类并依赖于what() - 返回文本的比较，那将非常“脆弱”，因为投掷站点通常希望能够随心所欲地重新编写消息提高他们的清晰度和实用性。它也可能更慢。

如果你使用自己的类，你可以更容易 以结构化的方式丰富它 ，也许会提供错误的一些细节，或者当错误处理时正在处理遇到了可以轻松可靠地使用的其他变量。这可以与在文本中嵌入新数据的事后调整形成对比，这可能使当前代码与对“样式”和可能长度的消息的期望混淆（例如，它可能会“吹灭”对话框，因此它不会干净地适应屏幕），并且文本需要变得严格结构化（例如移动到XML）或者容易出错解析....

Answer 2

它允许您制作针对特定API定制的异常，同时还遵守std::exception提供的基本合同。这允许您在main()或DLL或.so文件的入口点提供一个包含所有异常处理程序，以防止异常泄露出您的程序。

为什么要创建一个源自stdexcept Header的异常对象？

2 个答案: