【问题标题】:Final variable assignment with try/catch使用 try/catch 进行最终变量赋值
【发布时间】:2012-11-28 11:33:47
【问题描述】:

因为我相信这是一种很好的编程习惯,所以我将所有(本地或实例)变量设为final,如果它们打算只编写一次的话。

但是,我注意到当变量赋值可能引发异常时,您不能将所述变量设为 final:

final int x;
try {
    x = Integer.parseInt("someinput");
}
catch(NumberFormatException e) {
    x = 42;  // Compiler error: The final local variable x may already have been assigned
}

有没有办法在不使用临时变量的情况下做到这一点? (或者这不是最终修饰符的正确位置吗?)

【问题讨论】:

  • 我怀疑你可以在没有临时变量的情况下做到这一点。
  • final int x = makeX(); 绝对。 (函数中的try-catch)
  • 令人震惊的是 JDK still doesn't have a tryParse.
  • 说清楚一点,编译器错误是不对的,不是吗?在给定的示例中,没有任何情况可以将 x 分配两次。
  • @jaco0646,当 try 块中有多行可能发生异常时,编译器通常要求很多。不过,最好有一个例外情况用于此目的,检测赋值何时是 try 中的最后一条语句。

标签: java final


【解决方案1】:

一种方法是引入一个(非final)临时变量,但你说你不想这样做。

另一种方法是将代码的两个分支移动到一个函数中:

final int x = getValue();

private int getValue() {
  try {
    return Integer.parseInt("someinput");
  }
  catch(NumberFormatException e) {
    return 42;
  }
}

这是否实用取决于具体的用例。

总而言之,只要x 是一个适当范围的局部变量,最实用的通用方法可能是将其保留为非final。

另一方面,如果x 是成员变量,我的建议是在初始化期间使用非final 临时变量:

public class C {
  private final int x;
  public C() {
    int x_val;
    try {
      x_val = Integer.parseInt("someinput");
    }
    catch(NumberFormatException e) {
      x_val = 42;
    }
    this.x = x_val;
  }
}

【讨论】:

  • 对于本地范围我同意你的观点,但是这最常发生在实例变量中。
  • 我猜这可能反映了一个错误无法对非静态方法getValue()进行静态引用,所以我们假设使用静态函数,我可能是错误的私有静态int getValue( ) ..@NPE
  • 如果 this.x 是像 Integer 这样的对象类型,那么你需要更多(遗憾)。如果您未声明 x_val,编译器将抱怨它可能尚未初始化。如果 catch 块的回退为 null,则需要预先初始化为 null,并在 catch 中冗余地分配 null 以清楚起见(这是我的偏好),或者有一个空的 catch。
  • @JoshuaGoldberg 所说的即使对于原始类型也是如此。我们有完全相同的代码模式,其中this.x 角色的成员是原始boolean,局部变量也是。即使使用 Java 9,我们也会得到“x_val> 可能尚未初始化”。这种情况下缺乏控制流分析令人沮丧,但很容易解决。
【解决方案2】:

不,这不是正确的地方,假设您在 try 和 catch 块中有超过 1 个语句,第一个语句说:x = 42。在其他一些语句之后,try 块失败,它进入 catch 块, 你说的 x = 30。现在你定义了 x 两次。

【讨论】:

  • 编译器足够聪明,可以知道哪些语句会抛出哪些异常。这可能并非在所有情况下都是可能的,但就像编译器在某些情况下可以告诉您有关死代码等一样。它应该能够确定 final 是否可以工作。
  • 为了支持@Stefan 所说的,Clang 在编译 Swift 时能够解决这个问题。
猜你喜欢
  • 1970-01-01
  • 2014-08-09
  • 2019-08-19
  • 2013-06-20
  • 2013-12-04
  • 2018-10-03
  • 1970-01-01
  • 2023-01-25
  • 1970-01-01
相关资源
最近更新 更多