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がコンパイルを妨げない到達不能コードのクラスがたくさんあることを指摘しています。ゲーデルの結果を正しく理解していれば、到達不能コードのすべてのクラスをキャッチできるコンパイラはないでしょう。

ユニットテストでは、すべてのバグを検出できるわけではありません。私たちはこれを彼らの価値に対する議論として使用しません。同様に、コンパイラは問題のあるコードをすべてキャッチすることはできませんが、可能であれば不正なコードのコンパイルを防ぐことは依然として価値があります。

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」の両方のブランチがオブジェクトと互換性のあるもの（ローカルvar＃0）にのみ格納されていることを確認します（3行目以降のコードがローカルvar＃0を処理する方法であるため） ）。

コンパイラが到達不能コードに到達すると、その時点でスタックがどのような状態にあるかが完全にはわからないため、その状態を確認できません。ローカル変数も追跡できないため、その時点でコードを完全にコンパイルすることはできません。そのため、このあいまいさをクラスファイルに残す代わりに、致命的なエラーが発生します。

もちろん、のような単純な条件if (1<2)はそれをだますでしょうが、それは実際にはだまされていません-それはコードにつながる可能性のある分岐を与えており、少なくともコンパイラとVMの両方がそこからスタックアイテムをどのように使用できるかを決定できますオン。

PSこの場合、.NETが何をするのかわかりませんが、コンパイルも失敗すると思います。これは通常、マシンコードコンパイラ（C、C ++、Obj-Cなど）では問題になりません。

コンパイラの目標の1つは、エラーのクラスを除外することです。到達不能コードが偶然に存在します。javacがコンパイル時にそのクラスのエラーを除外するのは素晴らしいことです。

誤ったコードをキャッチするすべてのルールについて、誰かがコンパイラーにそれを受け入れてもらいたいと思うでしょう。これはコンパイラチェックのペナルティであり、バランスを正しく取ることが言語設計のトリッキーなポイントの1つです。厳密なチェックを行っても、作成できるプログラムの数は無限にあるため、それほど悪くはありません。

このコンパイラエラーは良いことだと思いますが、回避する方法があります。真になることがわかっている条件を使用します。

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;コンパイラtrueはフラグではない（変数ではない）ことを「知っている」ため、コンパイル時エラーを生成しないという事実は、CodeNotReachable例外を生成するポリシーに矛盾があるように見えます。

興味深いかもしれないが、メソッドのコードの一部をオフにすることには適用されない他の2つの方法とif (true) return：

さて、言う代わりに、jvm引数if (true) return;に言っassert falseて追加-ea OR -ea package OR -ea classNameしたいかもしれません。良い点は、これによりある程度の粒度が可能になり、jvm呼び出しに追加のパラメーターを追加する必要があるため、コードにDEBUGフラグを設定する必要はありませんが、実行時に引数を追加することで、ターゲットがターゲットでない場合に役立ちます。開発者マシンとバイトコードの再コンパイルと転送には時間がかかります。

System.exit(0)方法もありますが、これはやり過ぎかもしれません。JSPのJavaに配置すると、サーバーが終了します。

Javaが設計上「乳母」言語であることは別として、制御を強化するためにC / C ++のようなネイティブのものを使用したいと思います。