Why doesn't Java allow generic subclasses of Throwable?

As mark said, the types are not reifiable, which is a problem in the following case:

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

Both SomeException<Integer> and SomeException<String> are erased to the same type, there is no way for the JVM to distinguish the exception instances, and therefore no way to tell which catch block should be executed.

Here is a simple example of how to use the exception:

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

The body of the TRy statement throws the exception with a given value, which is caught by the catch clause.

In contrast, the following definition of a new exception is prohibited, because it creates a parameterized type:

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

An attempt to compile the above reports an error:

% javac ParametricException.javaParametricException.java:1: a generic class may not extendjava.lang.Throwableclass ParametricException<T> extends Exception {  // compile-time error                                     ^1 error

This restriction is sensible because almost any attempt to catch such an exception must fail, because the type is not reifiable. One might expect a typical use of the exception to be something like the following:

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

This is not permitted, because the type in the catch clause is not reifiable. At the time of this writing, the Sun compiler reports a cascade of syntax errors in such a case:

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

Because exceptions cannot be parametric, the syntax is restricted so that the type must be written as an identifier, with no following parameter.

It's essentially because it was designed in a bad way.

This issue prevents clean abstract design e.g.,

public interface Repository<ID, E extends Entity<ID>> {    E getById(ID id) throws EntityNotFoundException<E, ID>;}

The fact that a catch clause would fail for generics are not reified is no excuse for that.The compiler could simply disallow concrete generic types that extend Throwable or disallow generics inside catch clauses.