即使分配是try中的最后一个操作，也可以在catch中重新分配最终变量吗？

赖浩荡

2023-03-14

问题内容：

我很相信这里

final int i;
try { i = calculateIndex(); }
catch (Exception e) { i = 1; }

i如果控制到达捕获块，则不可能已经分配。但是，Java编译器不同意并主张the final local variable i may already have been assigned。

我在这里仍然缺少一些微妙之处，还是这仅仅是Java语言规范用来识别潜在重新分配的模型的弱点？我主要担心的是Thread.stop()，可能会导致异常抛出“异常”，但是我仍然看不到分配后如何抛出异常，这显然是try块中的最后一个动作。

如果允许，上述成语会使我的许多方法变得更简单。请注意，该用例在诸如Scala之类的语言中具有一流的支持，这些语言始终采用 Maybe monad：

final int i = calculateIndex().getOrElse(1);

我认为这种使用情况作为一个相当不错的动力，让其中的一个特殊情况 i是 绝对未分配 的捕捉块内。

更新

经过一番思考，我甚至可以确定这只是JLS模型的弱点：如果我声明公理“在所示示例中，i当控制权到达catch-
block时绝对未分配”，它将不会与任何其他公理冲突或定理。在将i其分配给catch块之前，编译器将不允许对其进行任何读取，因此i无法观察是否分配了该事实。

问题答案：

这是对最有力论点的总结，以支持这样的论点：当前的定值分配规则必须在不破坏一致性的前提下放宽（A），然后再提出我的反驳（B）：

答：在字节码级别，对变量的写入不是try块中的最后一条指令：例如，最后一条指令通常是goto对异常处理代码的跳转；
乙：但是，如果规则状态i是 绝对未分配 的捕捉块内，它的值可以不被观察到。不可观察的价值与没有价值一样好。
答：即使编译器声明i为 绝对未分配 ，调试工具仍然可以看到该值；
B ：实际上，调试工具始终可以访问未初始化的局部变量，该变量在典型的实现中将具有任意值。未初始化的变量和在实际写入发生后突然完成初始化的变量之间没有本质区别。不管此处考虑的特殊情况如何，该工具都必须始终使用其他元数据来为每个局部变量知道 明确分配 该变量的指令范围，并且仅允许在执行发现自身处于该范围内时观察其值。

该规范可以持续接收更多细粒度的规则，这些规则可以使我发布的示例得以编译。