Question

我刚才读到，在C ++ 11标准修订版中，不推荐使用异常规范。我以前认为指定你的功能可能是好的做法，但显然不是这样。

在阅读Herb Stutter's well-cited article后，我不禁要问：为什么实际上是按照它们的方式实现了异常规范，为什么委员会决定弃用它们而不是在编译时检查它们？为什么编译器甚至允许抛出一个未出现在函数定义中的异常？对我来说，这听起来像是在说“你可能不应该指定你的函数返回类型，因为当你指定int f()但其中return 3.5;时，你的程序可能会崩溃。” （即，概念与强类型的区别在哪里？）

（由于typedef中缺少异常规范支持，假设模板语法可能是Turing-complete，实现这个听起来很容易。）

Answer 1

最初的原因是它被认为是不可能的鉴于现有代码的主体和事实，可靠地检查没有说明者意味着什么都可以抛出。意思就是如果静态检查有效，则以下代码不会编译：

double
safeSquareRoot( double d ) throw()
{
    return d > 0.0 ? sqrt( d ) : 0.0;
}

此外，例外的目的是报告错误距离很远，这意味着中间功能不应该知道他们调用的函数可能会抛出什么。要求它们的异常说明符会破坏封装

功能需要了解的唯一真实案例可能发生的异常是知道哪些异常不能发生。特别是，编写线程安全代码是不可能的除非你可以保证某些功能永远不会扔。即使在这里，静态检查也是不可接受的上面解释的原因，所以异常规范是旨在更像是一个你不能的断言停用：当你写throw()时，你会得到更多或更少的东西如果函数终止，则等效于断言失败例外。

Java中的情况有所不同。在Java中没有真正的输出参数，这意味着如果你不能如果函数也有返回值，则使用返回码。该结果是在许多情况下使用异常返回代码更可取。而这些，你必须这样做了解并立即处理。对于应该的事情真的是例外，Java有java.lang.RuntimeException （未经检查，静态或其他方式）。它没有说一个函数不能抛出异常的方式;它在其中使用未经检查的异常（称为Error）中止该计划会更合适。

Answer 2

如果函数f() throw(int)调用函数g() throw(int, double)会发生什么？

编译时检查会阻止你的函数使用不太严格的throw说明符调用任何其他函数，这将是一个巨大的痛苦。

为什么在编译时不检查C ++异常规范？

2 个答案: