Java为什么会有“无法到达的语句”编译器错误？

我经常在调试程序时发现在代码块内插入return语句很方便（尽管可能是不好的做法）。我可能会在Java中尝试类似的方法。

class Test {
        public static void main(String args[]) {
                System.out.println("hello world");
                return;
                System.out.println("i think this line might cause a problem");
        }
}

当然，这会产生编译器错误。

Test.java:7：无法访问的语句

我能理解为什么警告是合理的，因为有未使用的代码是不好的做法。但是我不明白为什么这需要产生一个错误。

这只是Java试图成为一个保姆，还是有充分的理由使它成为编译器错误？

因为无法到达的代码对编译器毫无意义。尽管使代码对人有意义不仅比使代码对编译器有意义更困难，但编译器是代码的基本使用者。Java设计人员认为对编译器没有意义的代码是错误。他们的立场是，如果您有一些无法访问的代码，那么您犯了一个错误，需要修复。

这里有一个类似的问题：无法访问的代码：错误还是警告？，其中作者说：“我个人强烈认为这应该是一个错误：如果程序员编写一段代码，则应该始终在某种情况下实际运行它。” 显然，Java的语言设计师对此表示同意。

无法访问的代码是否应该阻止编译是一个永远不会达成共识的问题。但这就是Java设计人员这样做的原因。

许多评论的人指出，Java无法阻止编译的许多类无法访问的代码。如果我正确理解了Gödel的后果，那么没有编译器可以捕获所有无法访问的代码类。

单元测试无法捕获每个错误。我们不以此为理由反对它们的价值。同样，编译器无法捕获所有有问题的代码，但对于它可以防止编译不良代码仍然很有价值。

Java语言设计人员将无法访问的代码视为错误。因此，在可能的情况下防止其编译是合理的。

（在降低表决权之前：问题不是Java是否应具有不可到达的语句编译器错误。问题是Java为什么会有不可达到的语句编译器错误。请不要仅仅因为您认为Java做出了错误的设计决定就对我进行表决。）

没有绝对的理由为什么不允许不可达的语句；其他语言允许他们没有问题。对于您的特定需求，这是通常的技巧：

if (true) return;

看起来很荒谬，任何阅读该代码的人都会猜测它一定是有意完成的，而不是一个使其余语句无法访问的粗心大意的错误。

Java对“条件编译”有一点支持

http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.21

if (false) { x=3; }

不会导致编译时错误。优化的编译器可能会意识到语句x = 3; 永远不会执行，可以选择从生成的类文件中省略该语句的代码，但是语句x = 3; 就此处指定的技术意义而言，“不被视为“无法访问”。

这种不同处理的原理是允许程序员定义“标志变量”，例如：

static final boolean DEBUG = false;

然后编写如下代码：

if (DEBUG) { x=3; }

这个想法是应该可以将DEBUG的值从false更改为true或从true更改为false，然后正确编译代码，而无需对程序文本进行其他更改。

是保姆。我觉得.Net正确地做到了这一点-它对无法访问的代码提出警告，但不是错误。对此有个警告，但我认为没有理由阻止编译（尤其是在调试会话期间，最好返回一个返回值以绕过某些代码）。

我只是注意到了这个问题，并想在此添加$ .02。

对于Java，这实际上不是一个选择。“无法到达的代码”错误并非来自JVM开发人员认为保护开发人员免受任何攻击或保持警惕的事实，而是来自JVM规范的要求。

Java编译器和JVM都使用所谓的“堆栈映射”-有关分配给当前方法的堆栈上所有项目的明确信息。必须知道堆栈中每个插槽的类型，以便JVM指令不会将一种类型的项目误认为另一种类型。这对于防止将数值用作指针非常重要。使用Java程序集可以尝试推送/存储数字，然后弹出/加载对象引用。但是，JVM将在类验证期间（即正在创建堆栈映射并测试一致性时）拒绝此代码。

为了验证堆栈映射，VM必须遍历方法中存在的所有代码路径，并确保无论执行哪个代码路径，每条指令的堆栈数据都应与之前的任何代码一致/存储在堆栈中。因此，在以下简单情况下：

Object a;
if (something) { a = new Object(); } else { a = new String(); }
System.out.println(a);

在第3行，JVM将检查'if'的两个分支是否仅存储到与Object兼容的东西（这只是本地var＃0）中（因为这是第3行及以后的代码将如何处理本地var＃0 ）。

当编译器获取到无法访问的代码时，它并不十分了解此时堆栈可能处于什么状态，因此无法验证其状态。此时它无法完全编译代码，因为它也无法跟踪局部变量，因此，它不会在类文件中留下这种歧义，而是产生致命错误。

当然，像这样的简单条件if (1<2)会使它傻瓜，但这并不是真正的愚弄-它为它提供了一个可能导致代码生成的潜在分支，并且至少编译器和VM都可以确定如何从那里使用堆栈项上。

PS我不知道.NET在这种情况下会做什么，但是我相信它也会使编译失败。对于任何机器代码编译器（C，C ++，Obj-C等），通常这都不是问题。

编译器的目标之一是排除错误类别。偶然地有一些无法访问的代码，javac在编译时排除了此类错误是很不错的。

对于捕获错误代码的每个规则，有人会希望编译器接受它，因为他们知道自己在做什么。那是编译器检查的代价，而正确地实现平衡是语言设计的关键点之一。即使经过最严格的检查，仍然可以编写无限数量的程序，因此事情不会那么糟。

尽管我认为此编译器错误是件好事，但有一种解决方法。使用您知道会成立的条件：

public void myMethod(){

    someCodeHere();

    if(1 < 2) return; // compiler isn't smart enough to complain about this

    moreCodeHere();

}

编译器不够聪明，无法对此抱怨。

抱怨编译器越严格越好，这当然是一件好事，只要它允许您执行所需的操作即可。通常，付出的小代价是注释掉代码，而好处是在编译代码时有效。一个典型的例子是Haskell，人们在知道自己的测试/调试只是主要测试而又是简短测试之前大喊大叫。我个人在Java中几乎（实际上是故意）不专心地进行调试。

如果允许的原因if (aBooleanVariable) return; someMoreCode;是允许标志，那么if (true) return; someMoreCode;不会产生编译时错误的事实似乎在生成CodeNotReachable异常的策略中不一致，因为编译器“知道”true不是标志（不是变量）。

另外两种可能很有趣的方式，但不适用于关闭方法的部分代码以及if (true) return：

现在，if (true) return;您可能不想说，而是要说assert false并添加-ea OR -ea package OR -ea className到jvm参数中。优点是，这允许一些粒度，并且需要在jvm调用中添加一个额外的参数，因此无需在代码中设置DEBUG标志，而需要在运行时添加参数，当目标不是目标时，这很有用。开发人员机器以及重新编译和传输字节码需要时间。

也有System.exit(0)办法，但是这可能是一个矫kill过正，如果将它放在Java中的JSP中，则它将终止服务器。

除了Java是一种设计为“保姆”的语言外，我宁愿使用诸如C / C ++之类的本机进行更多控制。