Почему Java не допускает общие подклассы Throwable?

Согласно спецификации языка Java , 3-е издание:

Это ошибка времени компиляции, если универсальный класс является прямым или косвенным подклассом Throwable.

Я хочу понять, почему это решение было принято. Что не так с общими исключениями?

(Насколько я знаю, дженерики - это просто синтаксический сахар во время компиляции, и они в Objectлюбом случае будут преобразованы в .classфайлы, поэтому объявление обобщения дженериков эффективно, как если бы все в нем было Object. Пожалуйста, исправьте меня, если я ошибаюсь .)

Как сказал Марк, типы не являются reifiable, что является проблемой в следующем случае:

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

Оба SomeException<Integer>и SomeException<String>стерты до одного и того же типа, у JVM нет способа различить экземпляры исключений и, следовательно, нет способа определить, какой catchблок должен быть выполнен.

Вот простой пример того, как использовать исключение:

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

Тело оператора TRy выдает исключение с заданным значением, которое перехватывается предложением catch.

Напротив, следующее определение нового исключения запрещено, поскольку оно создает параметризованный тип:

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

Попытка скомпилировать вышесказанное сообщает об ошибке:

% 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

Это ограничение имеет смысл, потому что почти любая попытка поймать такое исключение должна потерпеть неудачу, потому что тип не может быть переопределен. Можно ожидать, что типичное использование исключения будет выглядеть примерно так:

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

Это недопустимо, потому что тип в предложении catch не является пригодным для повторного использования. На момент написания этой статьи компилятор Sun сообщал о каскаде синтаксических ошибок в таком случае:

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

Поскольку исключения не могут быть параметрическими, синтаксис ограничен, поэтому тип должен быть записан как идентификатор без следующего параметра.

По сути, потому что он был спроектирован плохо.

Эта проблема предотвращает чистый абстрактный дизайн, например,

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

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

Тот факт, что предложение catch для дженериков не выполнено, не является оправданием. Компилятор может просто запретить конкретные обобщенные типы, которые расширяют Throwable или запрещать обобщенные типы внутри предложений catch.

Обобщения проверяются во время компиляции на корректность типов. Информация об общем типе затем удаляется в процессе, называемом стиранием типа . Например, List<Integer>будет преобразован в неуниверсальный тип List.

Из-за стирания типа параметры типа не могут быть определены во время выполнения.

Предположим, вам разрешено расширяться Throwableследующим образом:

public class GenericException<T> extends Throwable

Теперь давайте рассмотрим следующий код:

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

Из-за стирания типа среда выполнения не будет знать, какой блок catch выполнить.

Поэтому это ошибка времени компиляции, если универсальный класс является прямым или косвенным подклассом Throwable.

Источник: Проблемы с стиранием типов

Я ожидаю, что это потому, что нет способа гарантировать параметризацию. Рассмотрим следующий код:

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

Как вы заметили, параметризация - это просто синтаксический сахар. Тем не менее, компилятор пытается обеспечить согласованность параметров во всех ссылках на объект в области компиляции. В случае исключения компилятор не может гарантировать, что MyException выбрасывается только из области, которую он обрабатывает.