Perché Java non consente le sottoclassi generiche di Throwable?

Secondo la Java Language Sepecification , 3a edizione:

È un errore in fase di compilazione se una classe generica è una sottoclasse diretta o indiretta di Throwable.

Vorrei capire perché questa decisione è stata presa. Cosa c'è che non va nelle eccezioni generiche?

(Per quanto ne so, i generici sono semplicemente zucchero sintattico in fase di compilazione e verranno Objectcomunque tradotti nei .classfile, quindi dichiarare efficacemente una classe generica è come se tutto fosse in essa Object. Per favore correggimi se sbaglio .)

Come detto mark, i tipi non sono riutilizzabili, il che è un problema nel seguente caso:

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

Entrambi SomeException<Integer>e SomeException<String>vengono cancellati nello stesso tipo, non c'è modo per la JVM di distinguere le istanze di eccezione, e quindi non c'è modo di dire quale catchblocco debba essere eseguito.

Ecco un semplice esempio di come utilizzare l'eccezione:

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

Il corpo dell'istruzione TRy genera l'eccezione con un determinato valore, che viene catturato dalla clausola catch.

Al contrario, la seguente definizione di nuova eccezione è vietata, poiché crea un tipo con parametri:

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

Un tentativo di compilare quanto sopra riporta un errore:

% 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

Questa restrizione è ragionevole perché quasi tutti i tentativi di rilevare tale eccezione devono fallire, poiché il tipo non è riutilizzabile. Ci si potrebbe aspettare che un uso tipico dell'eccezione sia simile al seguente:

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

Ciò non è consentito, poiché il tipo nella clausola catch non è riutilizzabile. Al momento della stesura di questo documento, il compilatore Sun riporta una cascata di errori di sintassi in tal caso:

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

Poiché le eccezioni non possono essere parametriche, la sintassi è limitata in modo che il tipo debba essere scritto come identificatore, senza il seguente parametro.

È essenzialmente perché è stato progettato in modo negativo.

Questo problema impedisce un design pulito e astratto, ad es.

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

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

Il fatto che una clausola di cattura fallisca per i generici non viene reificata, non è una scusa per questo. Il compilatore potrebbe semplicemente non consentire tipi generici concreti che estendono Throwable o non consentano generici all'interno di clausole di cattura.

I generici sono controllati in fase di compilazione per la correttezza del tipo. Le informazioni sul tipo generico vengono quindi rimosse in un processo chiamato cancellazione del tipo . Ad esempio, List<Integer>verrà convertito nel tipo non genericoList .

A causa della cancellazione del tipo , i parametri del tipo non possono essere determinati in fase di esecuzione.

Supponiamo che ti sia permesso di estendere in Throwablequesto modo:

public class GenericException<T> extends Throwable

Consideriamo ora il seguente codice:

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

A causa della cancellazione del tipo , il runtime non saprà quale blocco catch eseguire.

Pertanto è un errore in fase di compilazione se una classe generica è una sottoclasse diretta o indiretta di Throwable.

Fonte: problemi con la cancellazione del tipo

Mi aspetto che sia perché non c'è modo di garantire la parametrizzazione. Considera il seguente codice:

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

Come notate, la parametrizzazione è solo zucchero sintattico. Tuttavia, il compilatore cerca di garantire che la parametrizzazione rimanga coerente tra tutti i riferimenti a un oggetto nell'ambito della compilazione. Nel caso di un'eccezione, il compilatore non ha modo di garantire che MyException venga generato solo da un ambito che sta elaborando.