Warum lässt Java generische Unterklassen von Throwable nicht zu?

Question

Nach den Java Language Sepecification, 3. Auflage:

It is a compile-time error if a generic class is a direct or indirect subclass of Throwable.

ich verstehen will, warum diese Entscheidung getroffen wurde. Was ist mit generischen Ausnahmen falsch?

(Soweit ich weiß, Generika sind einfach Kompilierung-syntaktischer Zucker, und sie werden zu Object ohnehin in den .class Dateien übersetzt werden, so effektiv eine generische Klasse zu erklären ist, als ob alles in ihm war ein Object. Bitte korrigieren Sie mich, wenn ich falsch liege)

Answer 1

als Mark sagte, sind die Typen nicht reifiable, was ein Problem im folgenden Fall ist:

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

Sowohl SomeException<Integer> und SomeException<String> auf die gleiche Art gelöscht werden, gibt es keine Möglichkeit für die JVM zu unterscheiden die Ausnahme-Instanzen und daher keine Möglichkeit zu sagen, welcher catch-Block ausgeführt werden soll.

Answer 2

Hier ist ein einfaches Beispiel dafür, wie die Ausnahme zu verwenden.

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

der Körper der try-Anweisung wirft die Ausnahme mit einem bestimmten Wert, der durch gefangen die Fangklausel.

Im Gegensatz dazu ist die folgende Definition einer neuen Ausnahme verboten, weil es eine parametrisierte Art erstellt:

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 Berichte einen Fehler zu kompilieren:

% 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, weil fast jeder Versuch, eine solche Ausnahme zu fangen, fehlschlagen muss, weil der Typ nicht verifizierbar ist. Man könnte eine typische Anwendung der Ausnahme erwartet in etwa wie folgt zu sein:

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, weil der Typ in der catch-Klausel nicht reifiable. Zum Zeitpunkt des Schreibens dieses Artikels, berichtet die Sun-Compiler eine Kaskade von Syntaxfehlern in einem solchen Fall:

% 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 kann, wird die Syntax beschränkt, so dass der Typ muss als Kennung geschrieben werden, ohne folgenden Parameter

Answer 3

Ich würde erwarten, dass es ist, weil 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, Parametrisierung ist nur syntaktischer Zucker. Der Compiler versucht jedoch sicherzustellen, dass die Parametrisierung für alle Verweise auf ein Objekt im Kompilierungsbereich konsistent bleibt. Im Falle einer Ausnahme kann der Compiler nicht garantieren, dass MyException nur von einem Bereich ausgelöst wird, den es verarbeitet.

Answer 4

Es ist im Wesentlichen, weil es auf eine schlechte Weise entworfen wurde.

Dieses Problem verhindert sauberes abstraktes Design, z.,

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

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

Die Tatsache, dass eine catch-Klausel für Generika scheitern würde nicht verdinglicht werden, ist keine Entschuldigung dafür. Der Compiler könnte einfach konkrete generische Typen verbieten, die Throwable oder Generics innerhalb von catch-Klauseln erweitern.

Answer 5

Generics werden zur Kompilierzeit auf Typkorrektheit überprüft. Die Information des generischen Typs wird dann in einem Prozeß Typ Löschen entfernt. Beispielsweise wird List<Integer> in den nicht generischen Typ List konvertiert.

Wegen Typ Typ löschen, Typ Parameter können nicht zur Laufzeit bestimmt werden.

Nehmen wir an, Sie dürfen Throwable wie folgt verlängern:

public class GenericException<T> extends Throwable 

Nun wollen wir den folgenden Code betrachten:

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

Aufgrund Typ Löschung, wird die Laufzeit nicht wissen, welche Fang Block zum Ausführen.

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

Quelle:Problems with type erasure