Pourquoi Java n'autorise-t-il pas les sous-classes génériques de Throwable?

Selon la spécification du langage Java , 3e édition:

Il s'agit d'une erreur de compilation si une classe générique est une sous-classe directe ou indirecte de Throwable.

Je souhaite comprendre pourquoi cette décision a été prise. Quel est le problème avec les exceptions génériques?

(Autant que je sache, les génériques sont simplement du sucre syntaxique au moment de la compilation, et ils seront traduits de Objecttoute façon dans les .classfichiers, donc déclarer efficacement une classe générique est comme si tout ce qu'elle contient était un Object. Veuillez me corriger si je me trompe .)

Comme Mark l'a dit, les types ne sont pas réifiables, ce qui pose un problème dans le cas suivant:

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

Les deux SomeException<Integer>et SomeException<String>sont effacés au même type, il n'y a aucun moyen pour la JVM de distinguer les instances d'exception, et donc aucun moyen de dire quel catchbloc doit être exécuté.

Voici un exemple simple d'utilisation de l'exception:

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

Le corps de l'instruction TRy lève l'exception avec une valeur donnée, qui est interceptée par la clause catch.

En revanche, la définition suivante d'une nouvelle exception est interdite, car elle crée un type paramétré:

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

Une tentative de compilation de ce qui précède signale une erreur:

% 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

Cette restriction est judicieuse car presque toute tentative pour intercepter une telle exception doit échouer, car le type n'est pas réifiable. On peut s'attendre à ce qu'une utilisation typique de l'exception ressemble à ce qui suit:

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

Cela n'est pas autorisé, car le type dans la clause catch n'est pas réifiable. Au moment d'écrire ces lignes, le compilateur Sun signale une cascade d'erreurs de syntaxe dans un tel cas:

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

Étant donné que les exceptions ne peuvent pas être paramétriques, la syntaxe est restreinte de sorte que le type doit être écrit en tant qu'identificateur, sans paramètre suivant.

C'est essentiellement parce qu'il a été mal conçu.

Ce problème empêche une conception abstraite propre, par exemple

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

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

Le fait qu'une clause catch échouerait si les génériques ne sont pas réifiés n'est pas une excuse pour cela. Le compilateur pourrait simplement interdire les types génériques concrets qui étendent Throwable ou interdire les génériques à l'intérieur des clauses catch.

Les génériques sont vérifiés au moment de la compilation pour la correction du type. Les informations de type générique sont ensuite supprimées dans un processus appelé effacement de type . Par exemple, List<Integer>sera converti en type non génériqueList .

En raison de l' effacement du type , les paramètres de type ne peuvent pas être déterminés au moment de l'exécution.

Supposons que vous êtes autorisé à vous étendre Throwablecomme ceci:

public class GenericException<T> extends Throwable

Considérons maintenant le code suivant:

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

En raison de l' effacement du type , le runtime ne saura pas quel bloc catch exécuter.

C'est donc une erreur de compilation si une classe générique est une sous-classe directe ou indirecte de Throwable.

Source: problèmes d'effacement de type

Je suppose que c'est parce qu'il n'y a aucun moyen de garantir le paramétrage. Considérez le code suivant:

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

Comme vous le notez, le paramétrage n'est que du sucre syntaxique. Cependant, le compilateur essaie de s'assurer que le paramétrage reste cohérent dans toutes les références à un objet dans la portée de compilation. Dans le cas d'une exception, le compilateur n'a aucun moyen de garantir que MyException est uniquement levée à partir d'une étendue qu'il traite.