JavaがThrowableのジェネリックサブクラスを許可しないのはなぜですか？

Java Language Sepecification、第3版によると：

ジェネリッククラスがの直接または間接サブクラスである場合、コンパイル時エラーになりますThrowable。

この決定がなされた理由を理解したいと思います。一般的な例外の何が問題になっていますか？

（私が知る限り、ジェネリックは単にコンパイル時の構文糖でありObject、.classファイル内でとにかく翻訳されるので、ジェネリッククラスを効果的に宣言することは、すべてがであるかのように行われますObject。間違っている場合は修正してください。）

マークが言ったように、タイプはreifiableではありません、それは次の場合の問題です：

try {
   doSomeStuff();
} catch (SomeException<Integer> e) {
   // ignore that
} catch (SomeException<String> e) {
   crashAndBurn()
}

両方SomeException<Integer>とSomeException<String>同じタイプに消去される、JVMは例外インスタンスを区別するための方法、及びその言うことは決してありませんcatch実行されるべきブロック。

例外の使用方法の簡単な例を次に示します。

class IntegerExceptionTest {
  public static void main(String[] args) {
    try {
      throw new IntegerException(42);
    } catch (IntegerException e) {
      assert e.getValue() == 42;
    }
  }
}

TRyステートメントの本文は、指定された値で例外をスローし、catch句によってキャッチされます。

対照的に、パラメーター化された型を作成するため、次の新しい例外の定義は禁止されています。

class ParametricException<T> extends Exception {  // compile-time error
  private final T value;
  public ParametricException(T value) { this.value = value; }
  public T getValue() { return value; }
}

上記をコンパイルしようとすると、エラーが報告されます。

% javac ParametricException.java
ParametricException.java:1: a generic class may not extend
java.lang.Throwable
class ParametricException<T> extends Exception {  // compile-time error
                                     ^
1 error

この制限は賢明です。なぜなら、そのような例外をキャッチしようとするほとんどすべての試みは失敗しなければならないからです。これは、型が再変換可能ではないためです。例外の一般的な用途は次のようなものであると期待できます。

class ParametricExceptionTest {
  public static void main(String[] args) {
    try {
      throw new ParametricException<Integer>(42);
    } catch (ParametricException<Integer> e) {  // compile-time error
      assert e.getValue()==42;
    }
  }
}

これは許可されていません。catch節のタイプは再設定できないためです。この記事の執筆時点では、Sunコンパイラはそのような場合に一連の構文エラーを報告しています。

% javac ParametricExceptionTest.java
ParametricExceptionTest.java:5: <identifier> expected
    } catch (ParametricException<Integer> e) {
                                ^
ParametricExceptionTest.java:8: ')' expected
  }
  ^
ParametricExceptionTest.java:9: '}' expected
}
 ^
3 errors

例外はパラメトリックにすることはできないため、構文は制限されているため、型は識別子として記述する必要があり、後続のパラメーターはありません。

それは本質的にそれが悪い方法で設計されたからです。

この問題により、きれいな抽象的なデザインが妨げられます。

public interface Repository<ID, E extends Entity<ID>> {

    E getById(ID id) throws EntityNotFoundException<E, ID>;
}

ジェネリックが具体化されていない場合、catch句が失敗するという事実はその言い訳にはなりません。コンパイラーは、Throwableを拡張する具体的なジェネリック型を単に許可しないか、catch句内のジェネリックを許可しない可能性があります。

ジェネリックスはコンパイル時に型が正しいかどうかチェックされます。ジェネリック型情報は、型消去と呼ばれるプロセスで削除されます。たとえばList<Integer>、非ジェネリック型に変換されListます。

型の消去のため、型パラメーターは実行時に決定できません。

Throwableこのように拡張することが許可されているとしましょう：

public class GenericException<T> extends Throwable

次のコードを考えてみましょう：

try {
    throw new GenericException<Integer>();
}
catch(GenericException<Integer> e) {
    System.err.println("Integer");
}
catch(GenericException<String> e) {
    System.err.println("String");
}

以下のために消去を入力し、実行時には、実行するためにどのキャッチブロックを知ることができません。

したがって、ジェネリッククラスがThrowableの直接または間接のサブクラスである場合、コンパイル時エラーになります。

出典： 型消去に関する問題

パラメータ化を保証する方法がないためだと思います。次のコードを検討してください。

try
{
    doSomethingThatCanThrow();
}
catch (MyException<Foo> e)
{
    // handle it
}

お気づきのように、パラメーター化は単なる構文上の砂糖です。ただし、コンパイラーは、パラメーター化がコンパイル範囲内のオブジェクトへのすべての参照にわたって一貫性を保つようにします。例外の場合、コンパイラーはMyExceptionが処理しているスコープからのみスローされることを保証する方法がありません。