Perché Java non consente sottoclassi generiche di Throwable?

Question

Secondo il Java Language Sepecification, 3a edizione:

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

Vorrei capire perché è stato preso questa decisione. Cosa c'è di sbagliato con le eccezioni generiche?

(Per quanto ne so, i generici sono semplicemente in fase di compilazione zucchero sintattico, e saranno tradotti in Object comunque nei file .class, così efficacemente dichiarando una classe generica è come se tutto ciò che è stato un Object. Si prega correggetemi se sbaglio)

Answer 1

Come marchio detto, i tipi non sono reifiable, che è un problema nel seguente caso:

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

Sia SomeException<Integer> e SomeException<String> vengono cancellati allo stesso tipo, non v'è alcun modo per il JVM distinguere le istanze di eccezione, e quindi nessun modo per dire quale blocco catch deve essere eseguito.

Answer 2

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 della dichiarazione try genera l'eccezione con un dato valore, che viene catturato da la clausola di cattura.

Al contrario, è vietata la seguente definizione di una nuova eccezione, perché crea un tipo parametrico:

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 i rapporti di cui sopra 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 ogni tentativo di catturare una tale eccezione deve fallire, perché il tipo non è reifiable. Ci si potrebbe aspettare un utilizzo tipico della deroga di essere qualcosa di simile a quanto segue:

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

Questo non è consentito, perché il tipo nella clausola catch non è reifiable. Al momento in cui scriviamo, il compilatore Sun riporta una cascata di errori di sintassi in un caso del genere:

% 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 parametrici, la sintassi è limitato in modo che il tipo deve essere scritto come un identificatore, senza parametro seguente

Answer 3

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

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

Come si nota, la parametrizzazione è solo zucchero sintattico. Tuttavia, il compilatore tenta 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 solo gettato da un ambito che sta elaborando.

Answer 4

È essenzialmente perché è stato progettato in modo negativo.

Questo problema impedisce un disegno astratto pulito 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 fallirebbe per i generici non sono reificati non è una scusa per quello. Il compilatore potrebbe semplicemente disabilitare i tipi generici concreti che estendono Throwable o impediscono i generici all'interno delle clausole catch.

Answer 5

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

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

Supponiamo che si è permesso di estendere la Throwable in questo 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"); 
} 

causa cancellazione del tipo, il runtime non saprà che cattura blocco da eseguire.

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

Fonte:Problems with type erasure