4 回答

TA贡献1863条经验 获得超2个赞
Java 认为那里的数组可能为空,但我知道它不能。
严格来说,Java 认为变量可以是未初始化的。如果未明确初始化,则该值不应该是可观察的。
(变量是静默初始化null
还是处于不确定状态是一个实现细节。关键是,语言说你不应该被允许看到这个值。)
但无论如何,解决方案是将其初始化为null
. 它是多余的,但是没有办法告诉 Java “只要相信我,它就会被初始化”。
在您收到“潜在的空指针访问”消息的变体中:
这是警告,不是错误。
您可以忽略或抑制警告。(如果您的正确性分析是错误的,那么您可能会得到 NPE。但这是您的选择。)
您可以使用编译器开关关闭部分或全部警告。
@SuppressWarnings
您可以使用注释抑制特定警告:对于 Eclipse,使用
@SuppressWarnings("null")
.对于 Android,请使用
@SuppressWarnings("ConstantConditions")
.不幸的是,警告标签并未完全标准化。但是,编译器应该默默地忽略
@SuppressWarnings
它无法识别的警告标记。您也许能够重组代码。
在您的示例中,代码正在使用 switch drop through。人们很少这样做,因为这会导致代码难以理解。因此,我并不感到惊讶,您可以找到涉及 drop-through 的边缘案例示例,在这种情况下,编译器会收到一些错误的 NPE 警告。
无论哪种方式,您都可以通过重构代码轻松地避免进行 drop-through 的需要。将案例中的代码复制到case 2:
案例末尾case 1:
。固定的。继续前行。
请注意,“可能未初始化”错误并不是 Java 编译器“愚蠢”。JLS 有一整章关于明确分配的规则,等等。不允许 Java 编译器对此很聪明,因为这意味着相同的 Java 代码将合法或不合法,具体取决于编译器的实现。这对代码的可移植性不利。
我们这里实际拥有的是一种语言设计折衷方案。该语言阻止您使用(实际上)未初始化的变量。但是要做到这一点,“愚蠢”的编译器有时必须阻止您使用您(聪明的程序员)知道将被初始化的变量……因为规则说它应该。
(替代方案更糟糕:要么不对未初始化的变量进行编译时检查,导致在不可预测的地方发生硬崩溃,要么对不同的编译器进行不同的检查。)

TA贡献1797条经验 获得超4个赞
在不顾 Eclipse 的抱怨而尝试执行代码之后,我注意到它确实运行没有问题。因此,尽管并不重要,但显然这只是一个被设置为“错误”级别的警告。
有一个“配置问题严重性”按钮,所以我将“潜在空指针访问”的严重性设置为“警告”(并相应地调整了其他一些级别)。现在 Eclipse 只是将其标记为警告并执行代码而没有抱怨。

TA贡献1772条经验 获得超8个赞
更容易理解的是:
boolean[] stuffNThings;
boolean initialized = false;
for (String string: list) {
if (!initialized) {
if (!/*condition*/) {
stuffNThings = new boolean[/*size*/];
initailized = true;
}
}
if (initialized) {
// bar
stuffNThings[0] = true;
}
}
两个循环,一个用于初始化,一个用于玩这些东西可能更清楚也可能不会更清楚。
流量分析更容易(与直通交换机相比)。
此外,也可能使用 a 而不是 a boolean[](BitSet因为它不是固定大小的数组)。
BitSet stuffNThings = new BitSet(/*max size*/);

TA贡献1772条经验 获得超6个赞
一个明显的非答案:当代码“如此”复杂以至于 IDE / java 编译器“看不到它”时,这很好地表明您的代码无论如何都太复杂了。至少对我来说,你说的话并不明显。我不得不反复上下阅读以说服自己问题中给出的陈述是正确的。
您在 for 的开关中有一个 if。干净的代码和“单层抽象”会告诉您:这不是一个好的起点。
看看你的代码。你所拥有的是一个伪装的状态机。问问自己是否值得在更大规模上重构它,例如将它变成某种显式状态机。
另一个侵入性较小的想法:使用列表而不是数组。然后您可以简单地创建一个空列表,并根据需要向其中添加元素。
添加回答
举报