函数签名中“Throw”的危险

虽然在函数签名中加入“throw”关键字可能很诱人明确声明潜在的例外情况，强烈建议不要这样做。尽管其目的看似简单，但有几个技术原因导致这种方法被认为是一个糟糕的选择。

编译器限制

编译器无法强制执行会产生一个重大问题函数签名中声明的异常规范。因此，编译器无法验证该函数是否确实会抛出指定的异常。这会导致潜在的误导性签名，因为该函数实际上可能会抛出不同的异常或根本不抛出任何异常。

运行时无效

在运行时检查异常规范，强加性能开销。与在编译时更有效地执行这些检查的现代异常处理机制相比，这是特别不可取的。

不一致的实现

异常规范在不同的环境中具有不同级别的支持编译器。例如，MSVC 在很大程度上忽略了异常规范，除了“throw()”这种特殊情况，它被解释为保证不会抛出异常。这种不一致会造成特定于平台的问题并使可移植性变得复杂。

异常规范的替代方案

考虑到在函数签名中使用“throw”的缺点，建议采用异常处理的替代方法。其中包括：

• 使用RAII（资源获取即初始化）技术来管理资源和处理潜在错误
• 使用异常类来明确定义和处理特定的异常场景
• 使用结构化异常处理机制提供编译时检查和更高效的异常处理