定义自己的异常类的最佳实践？答案

【问题标题】：Best practices for defining your own exception classes?定义自己的异常类的最佳实践？
【发布时间】：2010-10-15 20:44:48
【问题描述】：

我有一些特殊的异常情况想要抛出和捕获，所以我想定义自己的异常类。

这方面的最佳做法是什么？我应该从std::exception 还是std::runtime_error 继承？

【问题讨论】：

标签： c++ exception inheritance error-handling

【解决方案1】：

是的，从std::runtime_error 或other standard exception classes 像std::logic_error、std::invalid_argument 等等，这是一个很好的做法，这取决于它是哪种异常。

如果所有异常都以某种方式从std::exception 继承，则很容易通过catch(const std::exception &e) {...} 捕获所有常见错误。如果您有几个独立的层次结构，这将变得更加复杂。从专门的异常类中派生，使这些异常携带更多信息，但这究竟有多大用处取决于您如何处理异常。

【讨论】：

通过 const ref 捕获：catch(std::exception const& e)

【解决方案2】：

我不是 C++ 开发人员，但我们在 C# 代码中做的一件事是为我们的框架创建一个基类异常，然后在构造函数中记录抛出的异常：

  public FrameworkException(string message, Exception innerException)
      : base(message, innerException)
  {
      log.Error(message, innerException);
  }

  ...

任何派生异常只需要调用它的基本构造函数，我们就可以在整个过程中获得一致的异常日志记录。没什么大不了的，但很有用。

【讨论】：

你必须小心花哨的异常，特别是当异常本身的构造可能抛出异常时。

【解决方案3】：

将异常放在某个范围内是一件好事。比如Manipulation类可以在异常类中声明Error。

像这样抓住他们

catch ( const Manipulation::InputError& error )
catch ( const Manipulation::CalculationError& error )

在这种情况下，它们可能只是没有任何额外错误信息的空类，除非您的设计允许这些异常在您捕获所有标准异常的地方飞得更高。

【讨论】：

【解决方案4】：

这没什么大的不同，因为std::runtime_error 也继承自std::exception。您可能会争辩说，运行时错误传达了有关异常的更多信息，但实际上，人们通常只是从基异常类派生而来。

【讨论】：

【解决方案5】：

在我看来，是否从 std::exception 继承并不重要。对我来说，定义异常最重要的是：

使异常类名称有用且清晰。
清楚地记录（编写 cmets）何时异常会被函数或类方法抛出。在我看来，这是异常处理中最大的一个失败点。

【讨论】：