抛出异常是否由抽象机评估？

如何解决抛出异常是否由抽象机评估？

根据intro.abstract#1：

...需要遵循的实现来（仅）模拟抽象机的可观察行为，如下所述。

此解释是 as rule，其中包含以下示例：

...如果实际实现可以推断出未使用表达式的值并且不会产生影响程序可观察行为的副作用，则无需评估表达式的一部分。

副作用的定义在intro.execution#7中：

读取由易失性glvalue（[basic.lval]）指定的对象，修改对象，调用库I / O函数或调用执行任何这些操作的函数都是副作用，它们是执行环境的状态。 ...

在我看来，在以下程序中：

int main() 
{
  throw 42;
}

未使用表达式throw 42;的值，它不满足任何副作用标准。

这是否意味着允许实现不评估此表达式？上面的程序是否等效于：

int main() {}

就抽象机而言？我找不到任何文字说明抽象机知道或关心异常。

解决方法

（已编辑的）问题归结为是否允许编译器将int main() { throw 42; }“优化”到int main() { }。我相信在这种情况下答案是否定的，因为抛出的异常会导致程序的可观察行为发生变化，编译器必须模仿该行为。

由于未定义显式处理程序，因此应该throw 42;调用std::terminate()，然后最终调用std::abort()，其中“ 返回实现定义的状态指示执行失败的主机环境”。换句话说，程序的退出代码与vs.会有所不同，而不会抛出异常，因此throw不能被省略。

（这省去了没有“ host ”返回的独立实现的情况，但是我认为编译器无法对其运行环境进行假设）

在更一般的情况下，在用户代码中定义了一个显式匹配异常处理程序时，它变得更加模糊。引发异常会将控制权转移给该处理程序，但是 if 编译器可以确定该处理程序不会引起可观察到的行为或其他副作用的变化，然后是整个{{ 1}} 可能会被优化。在处理程序不访问任何易失性数据，不修改任何对象，不调用任何库I / O函数并执行与普通程序等效的程序退出的情况下，可能会发生这种情况。

,

再一次，我被证明对“好像规则”是正确的：在C或C ++中，没有更广为人知的子句。它甚至不是一个“规则”。这是对编程语言标准描述本质的提醒。

您只能将所谓的“规则”应用于程序；语句或表达式没有规则。 由于您没有一个结构合理且可以运行的程序，因此您的问题中没有所谓的适用规则。

如果您有一个可以运行的程序，则“规则”只是说一致性是通过测量程序I / O来定义的（包括易失性访问，这只是一种I / O像stdio，然后从main返回/调用exit）。

总结：这样的问题是没有意义的，您应该忘记有一个叫做“好像规则”的东西，因为它不能被变成一个独特的，可移动的规则。

（该答案适用于C，C ++，Java以及几乎所有“高级”的东西。）

注意

不使用表达式throw 42;的值，也没有使用 满足任何副作用标准。

由于throw表达式会引发异常，因此不会像42部分那样导致“值”。它的作用是：抛出异常，以停止正常的控制流并跳至异常处理程序，或者如果不存在异常，则完全退出程序。

就“抽象机”而言，抛出肯定会做些事情：它停止了抽象机中的通常执行。在抽象机中，您可以看到抛出的效果。

询问“抽象机”似乎与您的观点相矛盾，因为任何计算在抽象机中都是可见的，但抽象机不可见。

无论如何，所有这些论文仅证明了我的观点，即“抽象机器”，“好像规则” ...是有害的概念，不会帮助任何人。

只需考虑程序语义，该语义始终在所有高级语言中都以I / O的形式定义。其余所有内容！