第14章 ブロック、文およびパターン

すべての文には、特定の計算ステップが実行される通常の実行モードがあります。 次の各項では、各種類の文に対する通常の実行モードについて説明します。

説明どおりにすべてのステップが実行され、突然の完了が示されない場合、文は正常に完了と呼ばれます。 ただし、特定のイベントによって、ステートメントが正常に完了できない場合があります。

このようなイベントが発生した場合、1つ以上の文の実行は、その通常モードの実行のすべてのステップが完了する前に終了する可能性があります。このような文は突然完了と呼ばれます。

突然の完了には常に、次のいずれかの理由が関連付けられます。

「完全通常」と「完全突然」という用語は、式の評価にも適用されます(§15.6)。 式が突然完了できる唯一の理由は、指定された値を持つthrow (§14.18)または実行時例外またはエラー(§11 (例外)、§15.6)のいずれかが原因で例外がスローされることです。

文が式を評価する場合、式が突然完了すると、同じ理由で文の即時完了が常に発生します。 通常モードの実行では、後続のステップはすべて実行されません。

この章で特に指定されていないかぎり、サブステートメントの突然完了によって、同じ理由でステートメント自体がただちに突然完了し、ステートメントの実行の通常モードでの後続のステップはすべて実行されません。

特に指定しないかぎり、評価されるすべての式とそれが実行されるすべてのサブステートメントが正常に完了すると、ステートメントは通常どおりに完了します。

ブロックは、一連の文、ローカル変数宣言文、および中カッコ内のローカル・クラス宣言とインタフェース宣言です。

各ローカル変数宣言文および他の文を、最初の文から最後の(左から右)まで順に実行して、ブロックを実行します。 これらのブロック文がすべて正常に完了すると、ブロックは正常に完了します。 これらのブロック文のいずれかがなんらかの理由で突然完了した場合、そのブロックは同じ理由で突然完了します。

ローカル・クラスはネストされたクラス(§8 (Classes))で、宣言はブロック(§14.2)によって即時に含まれます。

ローカル・インタフェースはネストされたインタフェース(§9 (インタフェース))で、宣言はブロックによって即時に含まれます。

便宜上、ここでは次のプロダクションを示します。

ローカル・クラスおよびインタフェースの宣言は、含んでいるブロックの(ローカル変数宣言文を含む)文と自由に混ぜることができます。

ローカル・クラスまたはインタフェース宣言にアクセス修飾子public、protectedまたはprivate (§6.6)のいずれかがある場合、コンパイル時にエラーが発生します。

ローカル・クラスまたはインタフェース宣言に修飾子static (§8.1.1.4)、sealedまたはnon-sealed (§8.1.1.2、§9.1.1.4)が含まれている場合、コンパイル時にエラーが発生します。

ローカル・クラスの直接スーパークラスまたは直接スーパーインタフェースがsealedの場合、コンパイル時にエラーが発生します。

ローカル・インタフェースの直接スーパーインタフェースがsealedの場合、コンパイル時にエラーが発生します。

ローカル・クラスは、標準クラス(§8.1)、列挙クラス(§8.9)、またはレコード・クラス(§8.10)です。 各ローカル標準クラスは内部クラス(§8.1.3)です。 すべてのローカルenumクラスおよびローカル・レコード・クラスは暗黙的にstatic (§8.1.1.4)であるため、内部クラスではありません。

ローカル・インタフェースは、標準インタフェース(§9.1)にできますが、注釈インタフェース(§9.6)にはできません。 すべてのローカル・インタフェースは暗黙的にstaticです(§9.1.1.3)。

匿名クラス(§15.9.5)と同様に、ローカル・クラスまたはインタフェースは、パッケージ、クラスまたはインタフェースのメンバーではありません(§7.1、§8.5)。 匿名クラスとは異なり、ローカル・クラスまたはインタフェースには単純な名前(§6.2、§6.7)があります。

ローカル・クラスまたはインタフェース宣言のスコープおよびシャドウ化は、§6.3および§6.4で指定されています。

class Global {
    class Cyclic {}

    void foo() {
        new Cyclic(); // create a Global.Cyclic
        class Cyclic extends Cyclic {} // circular definition

        {
            class Local {}
            {
                class Local {} // compile-time error
            }
            class Local {} // compile-time error
            class AnotherLocal {
                void bar() {
                    class Local {} // ok
                }
            }
        }
        class Local {} // ok, not in scope of prior Local
    }
}

ローカル変数宣言は、1つ以上のローカル変数を宣言し、オプションで初期化します(§4.12.3)。

UnannTypeについては、§8.3を参照してください。 ここでは、便宜上、§4.3、§8.3、および §8.4.1からの次のプロダクションを示します。

ローカル変数宣言は次の場所で使用できます。

局所変数宣言の注釈修飾子に関する規則は、§9.7.4および§9.7.5で指定されています。

キーワードfinalがローカル変数宣言の修飾子として表示される場合、ローカル変数はfinal変数です(§4.12.4)。

finalがローカル変数宣言の修飾子として複数回出現した場合、コンパイル時にエラーが発生します。

(i)に識別子が含まれず、(ii)イニシャライザを持たないローカル変数宣言が、次のいずれかの場所に表示される場合、コンパイル時にエラーが発生します。

LocalVariableTypeがvarで、次のいずれかがtrueの場合、コンパイル時にエラーが発生します。

var a = 1;            // Legal
var b = 2, c = 3.0;   // Illegal: multiple declarators
var d[] = new int[4]; // Illegal: extra bracket pairs
var e;                // Illegal: no initializer
var f = { 6 };        // Illegal: array initializer
var g = (g = 7);      // Illegal: self reference in initializer

var a = 1;                // a has type 'int'
var b = java.util.List.of(1, 2);  // b has type 'List<Integer>'
var c = "x".getClass();   // c has type 'Class<? extends String>'
                          // (see JLS 15.12.2.6)
var d = new Object() {};  // d has the type of the anonymous class
var e = (CharSequence & Comparable<String>) "x";
                          // e has type CharSequence & Comparable<String>
var f = () -> "hello";    // Illegal: lambda not in an assignment context
var g = null;             // Illegal: null type

Javaプログラミング言語には多くの種類の文があります。 ほとんどの文は、CおよびC++言語の文に対応していますが、一部は一意です。

CおよびC++と同様に、Javaプログラミング言語のif文は、この誤解を招く形式の例で示した、いわゆる「ダングリングelse問題」に悩まされています。

if (door.isOpen())
    if (resident.isVisible())
        resident.greet("Hello!");
else door.bell.ring();  // A "dangling else"

問題は、外部のif文と内部if文の両方が、おそらくelse句を所有していることです。 この例では、プログラマがelse句を外部のif文に所属させることを想定していることがわかります。

CやC++などのJavaプログラミング言語とその前の多くのプログラミング言語は、else句が属している可能性のある最も内側のifに属することを任意に決定します。 このルールは、次の文法で取得されます。

ここでは、便宜上、§14.9からの次のプロダクションを示します。

したがって、文は文法的に2つのカテゴリに分けられます。つまり、else句がないif文(短いif文)で終わる場合があり、そうでない場合です。

短いif文で完全に終わらない文のみが、else句を持つif文でキーワードelseの前に即時のサブステートメントとして出現する可能性があります。

この単純なルールにより、ダングリングelseの問題が回避されます。 短いif制限のない文の実行動作は、「短いifなし」制限のない同じ種類の文の実行動作と同じです。この区別は、構文上の難しさを解決するためにのみ描画されます。

空の文は何も行いません。

空の文の実行は、常に正常に完了します。

文にはラベル接頭辞を含めることができます。

識別子は、すぐに含まれる文のラベルとして宣言されます。

CおよびC++とは異なり、Javaプログラミング言語にはgoto文はありません。識別子文のラベルは、ラベル付き文内の任意の場所に表示されるbreak文またはcontinue文(§14.15、§14.16)とともに使用されます。

ラベル付き文のラベルの有効範囲は、すぐに含まれる文です。

ラベル付きステートメントの名前がラベルのスコープ内で別のラベル付きステートメントのラベルとして使用される場合、コンパイル時にエラーが発生します。

ラベルと同じ識別子を使用し、パッケージ、クラス、インタフェース、メソッド、フィールド、パラメータまたはローカル変数の名前として使用することに対する制限はありません。 文にラベルを付けるための識別子の使用は、同じ名前のパッケージ、クラス、インタフェース、メソッド、フィールド、パラメータまたはローカル変数を不明瞭化しません(§6.4.2)。 クラス、インタフェース、メソッド、フィールド、ローカル変数、または例外ハンドラ(§14.20)のパラメータとしての識別子の使用は、同じ名前の文ラベルを隠すものではありません。

ラベル付き文は、すぐに含まれる文を実行することによって実行されます。

文に識別子のラベルが付けられ、含まれている文が、同じ識別子を持つbreakのために突然完了した場合、ラベル付き文は正常に完了します。 その他すべての文が突然完了した場合、ラベル付き文は同じ理由で突然完了します。

class Test {
    char[] value;
    int offset, count;
    int indexOf(TestString str, int fromIndex) {
        char[] v1 = value, v2 = str.value;
        int max = offset + (count - str.count);
        int start = offset + ((fromIndex < 0) ? 0 : fromIndex);
    i:
        for (int i = start; i <= max; i++) {
            int n = str.count, j = i, k = str.offset;
            while (n-- != 0) {
                if (v1[j++] != v2[k++])
                    continue i;
            }
            return i - offset;
        }
        return -1;
    }
}

特定の種類の式は、セミコロンを付けて文として使用できます。

式文は、式を評価することによって実行されます。式に値がある場合、その値は破棄されます。

式の実行は、式の評価が正常に完了した場合にのみ、正常に完了します。

CやC++とは異なり、Javaプログラミング言語では、特定の形式の式のみを式文として使用できます。 たとえば、メソッド呼出し式(§15.12)を使用することは有効です。

System.out.println("Hello world");  // OK

ただし、カッコで囲まれた式(§15.8.5)を使用することは無効です。

(System.out.println("Hello world"));  // illegal

Javaプログラミング言語では、voidへのキャストは許可されません。つまり、voidは型ではないため、従来のCでは次のような式文を記述することができません。

(void)... ;  // incorrect!

動作しません。 一方、Javaプログラミング言語では、式文の中で最も有用な種類の式をすべて使用でき、voidメソッドを呼び出すための式文として使用されるメソッド呼出しを必要としないため、このようなトリックはほとんど必要ありません。 トリックが必要な場合は、代入文(§15.26)または局所変数宣言文(§14.4)のいずれかをかわりに使用できます。

if文では、文または2つの文の条件付き実行を許可し、どちらか一方を実行しますが、両方は実行できません。

「式」のタイプはbooleanまたはBooleanである必要があります。そうしないと、コンパイル時にエラーが発生します。

アサーションは、ブール式を含むassert文です。 アサーションは、有効または無効のいずれかです。 アサーションが有効な場合、アサーションを実行するとブール式が評価され、式がfalseと評価されるとエラーが報告されます。 アサーションが無効になっている場合、アサーションの実行はまったく効果がありません。

プレゼンテーションを容易にするために、両方の形式のassert文の最初の式を式1と呼びます。 assert文の2番目の形式では、2番目の式を式2と呼びます。

Expression1のタイプがbooleanまたはBooleanでない場合、コンパイル時にエラーが発生します。

assert文の2番目の形式でExpression2が無効(§15.1)の場合、コンパイル時にエラーが発生します。

クラスまたはインタフェースが初期化を完了した後に実行されるassert文は、ホスト・システムがassert文を含む最上位クラスまたはインタフェースがアサーションを有効にしていると判断した場合にのみ有効になります。

最上位のクラスまたはインタフェースがアサーションを有効にするかどうかは、(i)最上位のクラスまたはインタフェースの初期化、および(ii)最上位のクラスまたはインタフェースにネストされたクラスまたはインタフェースの初期化のうち、最も早いものまで決定されます。 トップ・レベル・クラスまたはインタフェースでアサーションを有効にするかどうかは、確認後に変更できません。

クラスまたはインタフェースの初期化が完了する前に実行されるassert文が有効になります。

public class Foo {
    public static void main(String[] args) {
        Baz.testAsserts();
        // Will execute after Baz is initialized.
    }
}
class Bar {
    static {
        Baz.testAsserts();
        // Will execute before Baz is initialized!
    }
}
class Baz extends Bar {
    static void testAsserts() {
        boolean enabled = false;
        assert  enabled = true;
        System.out.println("Asserts " +
                           (enabled ? "enabled" : "disabled"));
    }
}

Asserts enabled
Asserts disabled

無効化されたassert文は何も行いません。 特に、Expression1もExpression2も(存在する場合)評価されません。 無効化されたassert文の実行は、常に正常に完了します。

有効なassert文は、最初にExpression1を評価することによって実行されます。 結果のタイプがBooleanの場合、ボックス化解除変換の対象となります(§5.1.8)。

Expression1の評価または後続のアンボクシング変換(ある場合)がなんらかの理由で突然完了した場合、assert文も同じ理由で突然完了します。

それ以外の場合、実行はExpression1の値に基づいて選択することで続行されます。

通常、アサーション・チェックは、プログラムの開発およびテスト中に有効化され、デプロイメントのために無効化されてパフォーマンスが向上します。

アサーションを無効にできるので、プログラムでは、アサーションに含まれる式が評価されることを想定してはなりません。 したがって、これらのブール式は一般に副作用がないはずです。 このようなブール式を評価しても、評価の完了後に表示される状態には影響しません。 アサーションに含まれるブール式が副作用を持つことは違法ではありませんが、アサーションが有効か無効かによってプログラムの動作が異なる可能性があるため、通常は不適切です。

これを考慮して、publicメソッドの引数チェックにアサーションを使用しないでください。 引数チェックは通常、メソッドの規約の一部であり、アサーションが有効か無効かに関係なく、この規約を支持する必要があります。

引数チェックにアサーションを使用する場合の2つ目の問題は、誤った引数によって適切な実行時例外(IllegalArgumentException、ArrayIndexOutOfBoundsException、NullPointerExceptionなど)が発生することです。 アサーションが失敗しても、適切な例外はスローされません。 繰り返しますが、publicメソッドの引数チェックにアサーションを使用することは違法ではありませんが、通常は不適切です。 AssertionErrorは捕捉されないことを意図していますが、捕捉することは可能であるため、try文のルールは、throw文の現在の処理と同様に、tryブロックに表示されるアサーションを処理する必要があります。

switch文は、式の値に応じて、制御を複数の文または式のいずれかに転送します。

式は、セレクタ式と呼ばれます。 セレクタ式の型は、char、byte、short、intまたは参照型である必要があります。そうしないと、コンパイル時にエラーが発生します。

Object obj = ...;
switch (obj) {
  case Integer i, Boolean b -> {
    ...       // Error! Is i or b initialized?
  }
  ...
}

Object obj = ...;
switch (obj) {
  case Integer i, Boolean _ -> {
    ...       // Error! Is i initialized?
  }
  ...
}

Object obj = ...;
switch (obj) {
  case Integer _, Boolean _ -> {
    ...       // Matches both an Integer and a Boolean
  }
  ...
}

int i = ...;
switch(i) {
    default ->
        System.out.println("Some other integer");
    case 42 -> // allowed
        System.out.println("42");
}

Object o = "Hello";
switch (o) {
    case String s:
        System.out.println("String: " + s );  // No break!
    case Integer i:
        System.out.println(i + 1);            // Error! Can be reached
                                              // without matching the
                                              // pattern `Integer i`
    default:
}

Object o = "Hello World";
switch (o) {
    case String s:
    case Integer i:
        System.out.println(i + 1);  // Error! Can be reached
                                    // without matching the
                                    // pattern `Integer i`
    default:
}
Object obj = null;
switch (obj) {
    case null:
    case String s:
        System.out.println(s);      // Error! Can be reached
                                    // without matching the
                                    // pattern `String s`
    default:
}

record R() {}
record S() {}
Object o = "Hello World";
switch (o) {
    case String s:
        System.out.println(s);      // No break
    case R():                       // No pattern variables declared
        System.out.println("It's either an R or a string");
        break;
    default:
}
Object ob = new R();
switch (ob) {
    case R():
    case S():                       // Multiple case labels
        System.out.println("Either R or an S");
        break;
    default:
}
Object obj = null;
switch (obj) {
    case null:
    case R():                       // Multiple case labels
        System.out.println("Either null or an R");
        break;
    default:
}

sealed interface I permits A, B, C {}
final class A   implements I {}
final class B   implements I {}
record C(int j) implements I {}  // Implicitly final
record Box(I i) {}

int testExhaustiveRecordPatterns(Box b) {
    return switch (b) {     // Exhaustive!
        case Box(A a) -> 0;
        case Box(B b) -> 1;
        case Box(C c) -> 2;
    };
}

record IPair(I i, I j){}

int testNonExhaustiveRecordPatterns(IPair p) {
    return switch (p) {     // Not Exhaustive!
        case IPair(A a, A a) -> 0;
        case IPair(B b, B b) -> 1;
        case IPair(C c, C c) -> 2;
    };
}

switch (day) {
    ...
    case SATURDAY, SUNDAY :
        System.out.println("It's the weekend!");
        break;
    ...
}

for (i = 0; i < n; ++i) foo();

int q = (n+7)/8;
switch (n%8) {
    case 0: do { foo();    // Great C hack, Tom,
    case 7:      foo();    // but it's not valid here.
    case 6:      foo();
    case 5:      foo();
    case 4:      foo();
    case 3:      foo();
    case 2:      foo();
    case 1:      foo();
            } while (--q > 0);
}

enum E { A, B, C }
E e = ...;
switch (e) {
   case A -> System.out.println("A");
   case B -> System.out.println("B");
   // No case for C!
}

Object o = ...;
switch (o) {    // Error - non-exhaustive switch!
    case String s -> System.out.println("A string!");
}

Object o = ...;
switch (o) {
    case String s -> System.out.println("A string!");
    default -> {}
}

class TooMany {
    static void howMany(int k) {
        switch (k) {
            case 1: System.out.print("one ");
            case 2: System.out.print("too ");
            case 3: System.out.println("many");
        }
    }
    public static void main(String[] args) {
        howMany(3);
        howMany(2);
        howMany(1);
    }
}

many
too many
one too many

class TwoMany {
    static void howMany(int k) {
        switch (k) {
            case 1: System.out.println("one");
                    break;  // exit the switch
            case 2: System.out.println("two");
                    break;  // exit the switch
            case 3: System.out.println("many");
                    break;  // not needed, but good style
        }
    }
    static void howManyAgain(int k) {
        switch (k) {
            case 1 -> System.out.println("one");
            case 2 -> System.out.println("two");
            case 3 -> System.out.println("many");
        }
    }
    public static void main(String[] args) {
        howMany(1);
        howMany(2);
        howMany(3);
        howManyAgain(1);
        howManyAgain(2);
        howManyAgain(3);
    }
}

one
two
many
one
two
many

while文は、「式」の値がfalseになるまで、「式」および「文」を繰り返し実行します。

「式」のタイプはbooleanまたはBooleanである必要があります。そうしないと、コンパイル時にエラーが発生します。

while文は、最初に式を評価することによって実行されます。 結果のタイプがBooleanの場合、ボックス化解除変換の対象となります(§5.1.8)。

式または後続のボックス化解除変換(ある場合)の評価がなんらかの理由で突然完了した場合、while文も同じ理由で突然完了します。

それ以外の場合は、結果の値に基づいて実行が続行されます。

do文は、「式」の値がfalseになるまで、「文」および「式」を繰り返し実行します。

「式」のタイプはbooleanまたはBooleanである必要があります。そうしないと、コンパイル時にエラーが発生します。

do文は、最初に文を実行することによって実行されます。 次の選択肢があります。

do文を実行すると、常に、含まれている文が少なくとも1回実行されます。

public static String toHexString(int i) {
    StringBuffer buf = new StringBuffer(8);
    do {
        buf.append(Character.forDigit(i & 0xF, 16));
        i >>>= 4;
    } while (i != 0);
    return buf.reverse().toString();
}

for文には次の2つの形式があります。

List<? extends Integer> l = ...
for (float i : l) ...

for (Iterator<Integer> #i = l.iterator(); #i.hasNext(); ) {
    float #i0 = (Integer)#i.next();
    ...

int sum(int[] a) {
    int sum = 0;
    for (int i : a) sum += i;
    return sum;
}

Map<String, Integer> histogram = ...;
double total = 0;
for (int i : histogram.values())
    total += i;
for (Map.Entry<String, Integer> e : histogram.entrySet())
    System.out.println(e.getKey() + " " + e.getValue() / total);
}

break文は、包含文から制御を転送します。

break文には、次の2種類があります。

ラベルなしのbreak文は、最も内側のswitch、while、doまたはfor文に制御を転送しようとします。この内側の文は、ブレーク・ターゲットと呼ばれ、すぐに正常に完了します。

ラベルIdentifierを持つbreak文は、ラベルと同じIdentifierを持つ包含ラベル付き文(§14.7)に制御を転送しようとします。その後、この包含文はブレーク・ターゲットと呼ばれ、すぐに正常に完了します。 この場合、ブレーク・ターゲットはswitch文、while文、do文またはfor文である必要はありません。

break文にブレーク・ターゲットがない場合、コンパイル時にエラーが発生します。

ブレーク・ターゲットに、break文を囲むメソッド、コンストラクタ、インスタンス・イニシャライザ、静的イニシャライザ、ラムダ式またはswitch式が含まれている場合は、コンパイル時にエラーが発生します。 つまり、非ローカル・ジャンプはありません。

ラベルなしのbreak文の実行は、常に突然完了します。理由は、ラベルなしのbreakです。

ラベルが「識別子」のbreak文の実行は、常に突然完了します。理由は、ラベルが「識別子」のbreakです。

これにより、break文が常に突然完了することが確認できます。

前述の説明では、tryブロックまたはcatch句にbreak文が含まれているブレーク・ターゲット内にtry文(§14.20)がある場合、制御がブレーク・ターゲットに転送される前に、それらのtry文のfinally句が順番に、最も内側から最も外側に順番に実行されるため、単に制御の転送ではなく、制御の転送が試行されます。 finally句が突然完了すると、break文によって開始された制御の転送が中断される可能性があります。

class Graph {
    int[][] edges;
    public Graph(int[][] edges) { this.edges = edges; }

    public Graph loseEdges(int i, int j) {
        int n = edges.length;
        int[][] newedges = new int[n][];
        for (int k = 0; k < n; ++k) {
edgelist:
{
            int z;
search:
{
            if (k == i) {
                for (z = 0; z < edges[k].length; ++z) {
                    if (edges[k][z] == j) break search;
                }
            } else if (k == j) {
                for (z = 0; z < edges[k].length; ++z) {
                    if (edges[k][z] == i) break search;
                }
            }

            // No edge to be deleted; share this list.
            newedges[k] = edges[k];
            break edgelist;
} //search

            // Copy the list, omitting the edge at position z.
            int   m  = edges[k].length - 1;
            int[] ne = new int[m];
            System.arraycopy(edges[k], 0, ne, 0, z);
            System.arraycopy(edges[k], z+1, ne, z, m-z);
            newedges[k] = ne;
} //edgelist
        }
        return new Graph(newedges);
    }
}

continue文は、while文、do文またはfor文でのみ発生し、これらの3種類の文は反復文と呼ばれます。 制御は、反復文のループ継続ポイントに渡されます。

continue文には、次の2種類があります。

ラベルなしのcontinue文は、最も内側のwhile、doまたはfor文に制御を転送しようとします。この内側の文はcontinue targetと呼ばれ、現在の反復をただちに終了し、新しい反復を開始します。

ラベルがIdentifierのcontinue文は、ラベルと同じIdentifierを持つ包含ラベル付き文(§14.7)に制御を転送しようとします。この包含文は、continue targetと呼ばれ、すぐに現在の反復を終了し、新しい反復を開始します。 この場合、続行ターゲットはwhile、doまたはfor文である必要があります。そうしないと、コンパイル時にエラーが発生します。

continue文にcontinueターゲットがない場合、コンパイル時にエラーが発生します。

continueターゲットに、continue文を囲むメソッド、コンストラクタ、インスタンス・イニシャライザ、静的イニシャライザ、ラムダ式またはswitch式が含まれている場合、コンパイル時にエラーが発生します。 つまり、非ローカル・ジャンプはありません。

ラベルなしのcontinue文の実行は、常に突然完了します。理由は、ラベルなしのcontinueです。

ラベルが「識別子」のcontinue文の実行は、常に突然完了します。理由は、ラベルが「識別子」のcontinueです。

これにより、continue文が常に突然完了することが確認できます。

continueによる異常終了の処理については、while文(§14.12)、do文(§14.13)およびfor文(§14.14)の説明を参照してください。

前述の説明では、tryブロックまたはcatch句にcontinue文が含まれているcontinueターゲット内にtry文(§14.20)がある場合、制御がcontinueターゲットに転送される前に、それらのtry文のfinally句が順番に最内から最外まで実行されます。 finally句が突然完了すると、continue文によって開始された制御の転送が中断される可能性があります。

class Graph {
    int[][] edges;
    public Graph(int[][] edges) { this.edges = edges; }

    public Graph loseEdges(int i, int j) {
        int n = edges.length;
        int[][] newedges = new int[n][];
edgelists:
        for (int k = 0; k < n; ++k) {
            int z;
search:
{
            if (k == i) {
                for (z = 0; z < edges[k].length; ++z) {
                    if (edges[k][z] == j) break search;
                }
            } else if (k == j) {
                for (z = 0; z < edges[k].length; ++z) {
                    if (edges[k][z] == i) break search;
                }
            }

            // No edge to be deleted; share this list.
            newedges[k] = edges[k];
            continue edgelists;
} //search

            // Copy the list, omitting the edge at position z.
            int   m  = edges[k].length - 1;
            int[] ne = new int[m];
            System.arraycopy(edges[k], 0, ne, 0, z);
            System.arraycopy(edges[k], z+1, ne, z, m-z);
            newedges[k] = ne;
        } //edgelists
        return new Graph(newedges);
    }
}

return文は、メソッド(§8.4、§15.12)またはコンストラクタ(§8.8、§15.9)の起動者に制御を戻します。

return文には、次の2種類があります。

return文は、最も内側のコンストラクタ、メソッドまたはラムダ式の実行者に制御を転送しようとします。この内側の宣言または式は、リターン・ターゲットと呼ばれます。 値Expressionを持つreturn文の場合、Expressionの値が呼出しの値になります。

return文にリターン・ターゲットがない場合は、コンパイル時にエラーが発生します。

戻りターゲットに、(i) return文を包含するインスタンスまたは静的イニシャライザ、または(ii) return文を包含するswitch式が含まれている場合は、コンパイル時にエラーが発生します。

値のないreturn文の戻りターゲットがメソッドであり、そのメソッドがvoidとして宣言されていない場合、コンパイル時にエラーが発生します。

return文の戻りターゲットがコンストラクタで、return文がこのコンストラクタのプロローグ(§8.8.7)に出現した場合、コンパイル時にエラーが発生します。

値Expressionを持つreturn文の戻りターゲットがコンストラクタまたはvoidと宣言されたメソッドのいずれかである場合、コンパイル時にエラーが発生します。

値Expressionを持つreturn文の戻りターゲットが、宣言された戻り型Tを持つメソッドであり、ExpressionのタイプがTとの代入互換性(§5.2)でない場合、コンパイル時にエラーが発生します。

値を指定しないreturn文の実行は、常に突然完了します。これは、値を指定しない戻り値の理由です。

値「式」を持つreturn文を実行すると、最初に「式」が評価されます。 式の評価がなんらかの理由で突然完了した場合、return文はその理由で突然完了します。 式の評価が正常に完了し、値Vが生成されると、return文が突然完了します。これは、値Vの戻り値の理由です。

これにより、return文が常に突然完了することが確認できます。

前述の説明では、tryブロックまたはcatch句にreturn文が含まれているメソッドまたはコンストラクタ内にtry文(§14.20)がある場合、それらのtry文のfinally句は、メソッドまたはコンストラクタの起動元に制御が転送される前に、最も内側から外側まで順番に実行されます。 finally句が突然完了すると、return文によって開始された制御の転送が中断される可能性があります。

throw文を使用すると、例外(§11 (例外))がスローされます。 この結果は、複数の文および複数のコンストラクタ、インスタンス・イニシャライザ、静的イニシャライザおよびフィールド・イニシャライザの評価、およびスローされた値を捕捉するtry文(§14.20)が見つかるまでメソッドの起動を終了する可能性がある制御(§11.3)の即時転送です。 そのようなtry文が見つからない場合、throwを実行したスレッド(§17 (Threads and Locks))の実行は、スレッドが属するスレッド・グループのuncaughtExceptionメソッドの呼出し後に終了します(§11.3)。

throw文の式は、Throwable型に代入可能な参照型(§5.2)の変数または値を示すか、null参照を示すか、コンパイル時にエラーが発生します。

式の参照型は、常にクラス型になります(インタフェース型がThrowableに割り当て可能でないため)。パラメータ化されません(Throwableのサブクラスを汎用にできないため(§8.1.2)。

次の3つの条件のうち少なくとも1つがtrueである必要があり、そうでない場合はコンパイル時にエラーが発生します。

throw文がスローできる例外型は、§11.2.2で指定します。

throw文では、最初に式が評価されます。 次に、

これにより、throw文が常に突然完了することが確認できます。

tryブロックにthrow文が含まれているtry文(§14.20)が囲まれている場合、これらのtry文のfinally句は、制御が外部に転送され、スローされた値が捕捉されるまで実行されます。 finally句が突然完了すると、throw文によって開始された制御の転送が中断される可能性があることに注意してください。

throw文がメソッド宣言またはラムダ式に含まれているが、その値がそれを含むtry文によって捕捉されない場合は、throwのためにメソッドの呼出しが突然完了します。

throw文がコンストラクタ宣言に含まれているが、その値がそれを含むtry文によって捕捉されない場合、コンストラクタを起動したクラス・インスタンス作成式は、throw (§15.9.4)のために突然完了します。

throw文が静的イニシャライザ(§8.7)に含まれている場合、コンパイル時チェック(§11.2.3)により、その値が常に未チェックの例外であるか、その値がそれを含むtry文によって常に捕捉されることが保証されます。 実行時に、このチェックにもかかわらず、throw文を含む一部のtry文によって値が捕捉されない場合、値がクラスErrorまたはそのサブクラスの1つのインスタンスである場合、値が再スローされます。それ以外の場合は、ExceptionInInitializerErrorオブジェクトにラップされ、その後スローされます(§12.4.2)。

throw文がインスタンス・イニシャライザ(§8.6)に含まれている場合、コンパイル時チェック(§11.2.3)により、その値が常に未チェックの例外であるか、その値がその値を含むtry文によって常に捕捉されるか、スローされた例外のタイプ(またはそのいずれかのスーパークラス)がクラスのすべてのコンストラクタのthrows句で発生します。

通常、ユーザー宣言のスロー可能型は、クラスThrowable (§11.1.1)のサブクラスであるクラスExceptionのサブクラスとして宣言する必要があります。

synchronized文は、実行スレッドにかわって相互排他ロック(§17.1)を取得し、ブロックを実行し、ロックを解放します。 実行中のスレッドがロックを所有している間は、ほかのスレッドがロックを取得することはできません。

式のタイプは参照型である必要があります。そうでない場合、コンパイル時にエラーが発生します。

synchronized文は、最初に式を評価することによって実行されます。 次に、

synchronized文によって取得されるロックは、synchronizedメソッドによって暗黙的に取得されるロックと同じです(§8.4.3.6)。 1つのスレッドがロックを複数回取得することがあります。

オブジェクトに関連付けられたロックを取得しても、他のスレッドがオブジェクトのフィールドにアクセスしたり、オブジェクトのsynchronized解除メソッドを呼び出したりすることを妨げられることはありません。 他のスレッドでは、synchronizedメソッドまたはsynchronized文を従来の方法で使用して相互の除外を実現することもできます。

class Test {
    public static void main(String[] args) {
        Test t = new Test();
        synchronized(t) {
            synchronized(t) {
                System.out.println("made it!");
            }
        }
    }
}

made it!

try文はブロックを実行します。 値がスローされ、try文にそれを捕捉できるcatch句が1つ以上ある場合、制御は最初のそのようなcatch句に転送されます。 try文にfinally句がある場合、tryブロックが正常に完了するか突然完了するかに関係なく、catch句が最初に制御されるかどうかに関係なく、別のコード・ブロックが実行されます。

UnannClassTypeについては、§8.3を参照してください。 ここでは、便宜上、§4.3、§8.3、および §8.4.1からの次のプロダクションを示します。

キーワードtryの直後のブロックは、try文のtryブロックと呼ばれます。

キーワードfinallyの直後のブロックは、try文のfinallyブロックと呼ばれます。

try文には、例外ハンドラとも呼ばれるcatch句を含めることができます。

catch句は、例外パラメータと呼ばれるパラメータを1つのみ宣言します。

finalが例外パラメータ宣言の修飾子として複数回出現する場合は、コンパイル時にエラーが発生します。

例外パラメータのスコープとシャドウは、§6.3および §6.4で指定されています。

ネストされたクラスまたはインタフェース、またはラムダ式からの例外パラメータへの参照は、§6.5.6.1で指定されているように制限されています。

例外パラメータは、その型を単一のクラス型または2つ以上のクラス型(代替と呼ばれる)の和集合として表すことができます。 結合の代替方法は、構文的に|で区切ります。

例外パラメータが単一のクラス型として示されるcatch句は、uni-catch句と呼ばれます。

例外パラメータが型の結合として示されるcatch句は、マルチcatch句と呼ばれます。

例外パラメータの型を示すために使用される各クラス型は、クラスThrowableまたはThrowableのサブクラスである必要があります。そうでない場合、コンパイル時にエラーが発生します。

例外パラメータの型を示すために型変数が使用された場合、コンパイル時にエラーが発生します。

タイプの和集合に2つの代替D_iおよびD_j (i ≠ j)が含まれている場合、コンパイル時にエラーが発生します。ここで、D_iはD_jのサブタイプです(§4.10.2)。

単一クラス型を持つ型を示す例外パラメータの宣言型は、そのクラス型です。

D₁ | D₂ | ... | D_nがlub(D₁、 D₂、 ...、 D_n)の和集合としてその型を示す例外パラメータの宣言型。

マルチcatch句の例外パラメータは、明示的にfinalを宣言しない場合、暗黙的にfinalを宣言します。

finalを暗黙的または明示的に宣言した例外パラメータがcatch句の本体内に割り当てられている場合、コンパイル時にエラーが発生します。

uni-catch句の例外パラメータは、暗黙的にfinalを宣言されることはありませんが、明示的にfinalを宣言することも、事実上finalにすることもできます(§4.12.4)。

暗黙的にfinal例外パラメータは、その宣言によってfinalですが、事実上最終的な例外パラメータは、その使用方法によってfinalです。 マルチcatch句の例外パラメータは暗黙的にfinalとして宣言されるため、代入演算子の左側のオペランドとして発生することはありませんが、事実上最終とはみなされません。

例外パラメータが実質的にfinal (uni-catch句内)または暗黙的にfinal (複数catch句内)の場合、明示的なfinal修飾子を宣言に追加しても、コンパイル時エラーは発生しません。 一方、uni-catch句の例外パラメータが明示的にfinalとして宣言されている場合、final修飾子を削除すると、コンパイル時にエラーが発生する可能性があります。これは、この例外パラメータは事実上最終とみなされるようになり、catch句の本体内の匿名クラス宣言およびローカル・クラス宣言によって参照されなくなったためです。 コンパイル時のエラーがない場合は、catch句の本体で例外パラメータが再割当てされるようにプログラムをさらに変更できるため、事実上最終とみなされなくなります。

try文がスローできる例外型は、§11.2.2で指定します。

try文のtryブロックによってスローされ、try文のcatch句(ある場合)によって捕捉される例外の関係は、§11.2.3で指定されます。

例外ハンドラは左から右の順に考慮されます。可能なかぎり早いcatch句は例外を受け入れ、§11.3で指定されているように、スローされた例外オブジェクトを引数として受け取ります。

try {
    ... throws ReflectiveOperationException ...
}
catch (ClassNotFoundException | IllegalAccessException ex) {
    ... body ...
}

try {
    ... throws ReflectiveOperationException ...
}
catch (final ClassNotFoundException ex1) {
    final ReflectiveOperationException ex = ex1;
    ... body ...
}
catch (final IllegalAccessException ex2) {
    final ReflectiveOperationException ex = ex2;
    ... body ...
}

finally句を使用すると、制御がtryブロックまたはcatchブロックをどのように残すかにかかわらず、finallyブロックがtryブロックおよび実行される可能性のあるcatchブロックの後に実行されます。 finallyブロックの処理はかなり複雑であるため、finallyブロックの有無にかかわらずtry文の2つのケースについて個別に説明します(§14.20.1、§14.20.2)。

try文は、catch句およびfinally句がtry-with-resources文(§14.20.3)の場合は省略できます。

class BlewIt extends Exception {
    BlewIt() { }
    BlewIt(String s) { super(s); }
}
class Test {
    static void blowUp() throws BlewIt { throw new BlewIt(); }

    public static void main(String[] args) {
        try {
            blowUp();
        } catch (RuntimeException r) {
            System.out.println("Caught RuntimeException");
        } catch (BlewIt b) {
            System.out.println("Caught BlewIt");
        }
    }
}

Caught BlewIt

class BlewIt extends Exception {
    BlewIt() { }
    BlewIt(String s) { super(s); }
}
class Test {
    static void blowUp() throws BlewIt {
        throw new NullPointerException();
    }
    public static void main(String[] args) {
        try {
            blowUp();
        } catch (BlewIt b) {
            System.out.println("Caught BlewIt");
        } finally {
            System.out.println("Uncaught Exception");
        }
    }
}

Uncaught Exception
Exception in thread "main" java.lang.NullPointerException
        at Test.blowUp(Test.java:7)
        at Test.main(Test.java:11)

try (VariableAccess ...)
    Block

try (T #r = VariableAccess ...) {
    Block
}

try ({VariableModifier} R VariableDeclaratorId = Expression ...)
    Block

{
    final {VariableModifierNoFinal} R Identifier = Expression;
    Throwable #primaryExc = null;

    try ResourceSpecification_tail
        Block
    catch (Throwable #t) {
        #primaryExc = #t;
        throw #t;
    } finally {
        if (Identifier != null) {
            if (#primaryExc != null) {
                try {
                    Identifier.close();
                } catch (Throwable #suppressedExc) {
                    #primaryExc.addSuppressed(#suppressedExc);
                }
            } else {
                Identifier.close();
            }
        }
    }
}

try ResourceSpecification
    Block
[Catches]
[Finally]

try {
    try ResourceSpecification
        Block
}
[Catches]
[Finally]

yield文では、囲んでいるswitch式(§15.28)によって指定された値が生成されるため、制御が転送されます。

yield文は、最も内側のswitch式に制御を転送しようとします。この内側の式は、イールド・ターゲットと呼ばれ、すぐに正常に完了し、式の値がswitch式の値になります。

yield文にyieldターゲットがない場合、コンパイル時にエラーが発生します。

yield文を囲むメソッド、コンストラクタ、インスタンス・イニシャライザ、静的イニシャライザまたはラムダ式がyieldターゲットに含まれている場合は、コンパイル時にエラーが発生します。 つまり、非ローカル・ジャンプはありません。

yield文の式が無効(§15.1)の場合、コンパイル時にエラーが発生します。

yield文を実行すると、最初に式が評価されます。 式の評価がなんらかの理由で突然完了した場合、yield文はその理由で突然完了します。 式の評価が正常に完了し、値Vが生成されると、yield文が突然完了します。この理由は、値Vを持つ結果です。

これにより、yield文が常に突然完了することが確認できます。

class Test {
    enum Day {
        MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY,
        SATURDAY, SUNDAY
    }

    public int calculate(Day d) {
        return switch (d) {
            case SATURDAY, SUNDAY -> d.ordinal();
            default -> {
                int len = d.toString().length();
                yield len*len;
            }
        };
    }
}

文が到達不能であるため実行できない場合、コンパイル時にエラーが発生します。

この項では、"到達可能"という言葉を正確に説明します。 それは、文を含むコンストラクタ、メソッド、インスタンス・イニシャライザまたは静的イニシャライザの先頭からその文自体までの実行パスが存在する必要があるという意味です。 分析では文の構造が考慮されます。 条件式が定数値trueを持つwhile文、do文およびfor文の特別な処理を除き、式の値はフロー分析では考慮されません。

{
    int n = 5;
    while (n > 7) k = 2;
}

この項で示すルールでは、次の2つの技術用語の意味を明らかにします。

ルールでは、文は、それに到達可能である場合のみ、正常完了可能です。

さらに2つの技術用語を使用します。

この規則は次のとおりです。

if文が次の方法で処理されることを想定している場合があります。

この方法は、他の制御構造の治療と一致します。 ただし、条件付きコンパイルの目的でif文を便利に使用できるようにするために、実際のルールは異なります。

例として、次の文を実行するとコンパイル時にエラーが発生します。

while (false) { x=3; }

文x=3;はアクセスできませんが、表面的には次のような場合です。

if (false) { x=3; }

コンパイル時にエラーが発生しません。 最適化コンパイラでは、文x=3;は実行されず、生成されたclassファイルからその文のコードを省略することを選択できますが、ここで指定する技術的な意味では、文x=3;は「到達不能」とはみなされません。

この異なる処置の根拠は、プログラマが次のようなフラグ変数を定義できるようにすることです。

static final boolean DEBUG = false;

次に、次のようなコードを記述します。

if (DEBUG) { x=3; }

DEBUGの値をfalseからtrueに変更するか、trueからfalseに変更してから、プログラム・テキストに他の変更を加えずにコードを正しくコンパイルすることが可能であるという考え方があります。

条件付きコンパイルには注意事項があります。 "flag"変数を使用する一連のクラス(より正確には、static定数変数(§4.12.4)がコンパイルされ、条件付きコードが省略された場合、フラグの定義を含む新しいバージョンのクラスまたはインタフェースのみを配布しても、後から十分ではありません。 このフラグを使用するクラスは、その新しい値を表示しないため、その動作は驚くかもしれません。 基本的に、フラグの値の変更は、既存のバイナリとのバイナリ互換性がありますが(LinkageErrorは発生しません)、動作互換性はありません。

static定数変数の値をインライン化するもう1つの理由は、switch文が原因です。 これらは、定数式に依存する唯一の種類の文です。つまり、switch文の各caseラベルは、値が他のすべてのcaseラベルと異なる定数式である必要があります。caseラベルは、多くの場合、static定数変数を参照するため、すべてのラベルに異なる値があることはすぐに明らかではない可能性があります。 コンパイル時に重複するラベルがないことが判明した場合は、classファイルに値をインライン化することで、実行時に重複するラベル(非常に望ましいプロパティ)がないことが保証されます。

class Flags { static final boolean DEBUG = true; }
class Test {
    public static void main(String[] args) {
        if (Flags.DEBUG)
            System.out.println("DEBUG is true");
    }
}

DEBUG is true

class Flags { static final boolean DEBUG = false; }

DEBUG is true

interface Flags { boolean DEBUG = true; }
class Test {
    public static void main(String[] args) {
        if (Flags.DEBUG)
            System.out.println("DEBUG is true");
    }
}

interface Flags {
    boolean debug = Boolean.valueOf(true).booleanValue();
}

パターンは、値に対して実行できるテストを示します。 パターンは文および式のオペランドとして出現し、テストする値を提供します。 パターンでは、0個以上のローカル変数(パターン変数とも呼ばれる)が宣言されます。

パターンに対して値をテストするプロセスは、パターン一致と呼ばれます。 値がパターンに正常に一致した場合、パターン・マッチングのプロセスは、パターンによって宣言されたパターン変数(ある場合)を初期化します。

パターン変数は、パターン一致が成功し、パターン変数が初期化されるスコープ(§6.3)にのみ存在します。 初期化されていないパターン変数を使用することはできません。