Mengapa Java tidak mengizinkan subclass generik dari Throwable?

Menurut Sepecification Bahasa Jawa , edisi ke-3:

Ini adalah kesalahan waktu kompilasi jika kelas generik adalah subkelas langsung atau tidak langsung dari Throwable.

Saya ingin memahami mengapa keputusan ini dibuat. Apa yang salah dengan pengecualian umum?

(Sejauh yang saya tahu, obat generik hanyalah kompilasi waktu sintaksis gula, dan mereka akan diterjemahkan ke Objectdalam .classfile, sehingga secara efektif menyatakan kelas generik adalah seolah-olah semua yang ada di dalamnya adalah Object. Tolong perbaiki saya jika saya salah .)

Seperti yang dikatakan oleh tanda, tipe tidak dapat diverifikasi, yang merupakan masalah dalam kasus berikut:

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

Keduanya SomeException<Integer>dan SomeException<String>terhapus ke tipe yang sama, tidak ada cara bagi JVM untuk membedakan instance pengecualian, dan oleh karena itu tidak ada cara untuk mengetahui catchblok mana yang harus dieksekusi.

Berikut adalah contoh sederhana cara menggunakan pengecualian:

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

Tubuh pernyataan COBALAH melempar pengecualian dengan nilai yang diberikan, yang ditangkap oleh klausa tangkapan.

Sebaliknya, definisi pengecualian baru berikut ini dilarang, karena itu menciptakan tipe parameter:

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

Upaya untuk mengkompilasi laporan di atas kesalahan:

% 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

Pembatasan ini masuk akal karena hampir semua upaya untuk menangkap pengecualian seperti itu harus gagal, karena jenisnya tidak dapat diverifikasi. Orang mungkin mengharapkan penggunaan pengecualian sebagai sesuatu seperti berikut ini:

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;
    }
  }
}

Ini tidak diizinkan, karena jenis dalam klausa tangkapan tidak dapat diverifikasi. Pada saat penulisan ini, kompiler Sun melaporkan kaskade kesalahan sintaksis dalam kasus seperti ini:

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

Karena pengecualian tidak bisa parametrik, sintaks dibatasi sehingga jenisnya harus ditulis sebagai pengidentifikasi, tanpa parameter berikut.

Ini pada dasarnya karena dirancang dengan cara yang buruk.

Masalah ini mencegah desain abstrak yang bersih misalnya,

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

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

Fakta bahwa klausa tangkapan akan gagal untuk obat generik tidak diverifikasi bukan alasan untuk itu. Kompiler hanya dapat melarang jenis generik beton yang memperpanjang Throwable atau melarang generik di dalam klausa tangkapan.

Generik diperiksa pada waktu kompilasi untuk ketepatan jenis. Informasi tipe umum kemudian dihapus dalam proses yang disebut tipe erasure . Misalnya, List<Integer>akan dikonversi ke jenis non-generik List.

Karena penghapusan tipe , parameter tipe tidak dapat ditentukan pada saat run-time.

Anggaplah Anda diizinkan untuk memperpanjang Throwableseperti ini:

public class GenericException<T> extends Throwable

Sekarang mari kita pertimbangkan kode berikut:

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

Karena tipe erasure , runtime tidak akan tahu blok tangkapan mana yang harus dieksekusi.

Oleh karena itu adalah kesalahan waktu kompilasi jika kelas generik adalah subclass langsung atau tidak langsung dari Throwable.

Sumber: Masalah dengan tipe erasure

Saya berharap itu karena tidak ada cara untuk menjamin parameterisasi. Pertimbangkan kode berikut:

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

Seperti yang Anda perhatikan, parameterisasi hanyalah gula sintaksis. Namun, kompiler mencoba memastikan bahwa parameterisasi tetap konsisten di semua referensi ke objek dalam lingkup kompilasi. Dalam kasus pengecualian, kompiler tidak memiliki cara untuk menjamin bahwa MyException hanya dibuang dari ruang lingkup yang sedang diproses.