Warum erlaubt Java keine generischen Unterklassen von Throwable?

Gemäß der Java Language Sepecification , 3. Auflage:

Es ist ein Fehler zur Kompilierungszeit, wenn eine generische Klasse eine direkte oder indirekte Unterklasse von ist Throwable.

Ich möchte verstehen, warum diese Entscheidung getroffen wurde. Was ist los mit generischen Ausnahmen?

(Soweit ich weiß, handelt es sich bei Generika lediglich um syntaktischen Zucker zur Kompilierungszeit, und sie werden Objectohnehin in die .classDateien übersetzt. Eine effektive Deklaration einer generischen Klasse ist also so, als ob alles darin eine wäre Object. Bitte korrigieren Sie mich, wenn ich falsch liege .)

Wie bereits erwähnt, sind die Typen nicht überprüfbar, was im folgenden Fall ein Problem darstellt:

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

Beide SomeException<Integer>und SomeException<String>werden für denselben Typ gelöscht. Die JVM kann die Ausnahmeinstanzen nicht unterscheiden und daher nicht festlegen, welcher catchBlock ausgeführt werden soll.

Hier ist ein einfaches Beispiel für die Verwendung der Ausnahme:

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

Der Hauptteil der TRy-Anweisung löst die Ausnahme mit einem bestimmten Wert aus, der von der catch-Klausel abgefangen wird.

Im Gegensatz dazu ist die folgende Definition einer neuen Ausnahme verboten, da dadurch ein parametrisierter Typ erstellt wird:

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

Ein Versuch, die oben genannten zu kompilieren, meldet einen Fehler:

% 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

Diese Einschränkung ist sinnvoll, da fast jeder Versuch, eine solche Ausnahme abzufangen, fehlschlagen muss, da der Typ nicht überprüfbar ist. Man könnte erwarten, dass eine typische Verwendung der Ausnahme etwa die folgende ist:

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

Dies ist nicht zulässig, da der Typ in der catch-Klausel nicht überprüfbar ist. Zum Zeitpunkt dieses Schreibens meldet der Sun-Compiler in einem solchen Fall eine Kaskade von Syntaxfehlern:

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

Da Ausnahmen nicht parametrisch sein können, ist die Syntax eingeschränkt, sodass der Typ als Bezeichner ohne folgenden Parameter geschrieben werden muss.

Es ist im Wesentlichen, weil es schlecht entworfen wurde.

Dieses Problem verhindert ein sauberes abstraktes Design, z.

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

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

Die Tatsache, dass eine Fangklausel für Generika fehlschlagen würde, ist keine Entschuldigung dafür. Der Compiler kann einfach konkrete generische Typen, die Throwable erweitern, verbieten oder Generika innerhalb von catch-Klauseln nicht zulassen.

Generika werden zur Kompilierungszeit auf Typkorrektheit überprüft. Die generischen Typinformationen werden dann in einem Prozess entfernt, der als Typlöschung bezeichnet wird . Zum Beispiel List<Integer>wird auf den nicht-generischen Typen umgewandelt werden List.

Aufgrund der Typlöschung können zur Laufzeit keine Typparameter ermittelt werden.

Nehmen wir an, Sie dürfen so erweitern Throwable:

public class GenericException<T> extends Throwable

Betrachten wir nun den folgenden Code:

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

Aufgrund der Löschung des Typs weiß die Laufzeit nicht, welcher Catch-Block ausgeführt werden soll.

Daher ist es ein Fehler zur Kompilierungszeit, wenn eine generische Klasse eine direkte oder indirekte Unterklasse von Throwable ist.

Quelle: Probleme beim Löschen des Typs

Ich würde erwarten, dass es keine Möglichkeit gibt, die Parametrisierung zu garantieren. Betrachten Sie den folgenden Code:

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

Wie Sie bemerken, ist Parametrisierung nur syntaktischer Zucker. Der Compiler versucht jedoch sicherzustellen, dass die Parametrisierung über alle Verweise auf ein Objekt im Kompilierungsbereich hinweg konsistent bleibt. Im Falle einer Ausnahme kann der Compiler nicht garantieren, dass MyException nur aus einem Bereich ausgelöst wird, den er verarbeitet.