Чому Java не допускає загальні підкласи Throwable?

Відповідно до специфікації мови Java , 3-е видання:

Це помилка часу компіляції, якщо загальний клас є прямим або непрямим підкласом Throwable.

Я хочу зрозуміти, чому було прийнято таке рішення. Що не так із загальними винятками?

(Наскільки я знаю, дженерики - це просто синтаксичний цукор за часом компіляції, і вони будуть переведені у Objectбудь-який .classфайл у файли, тому ефективне оголошення загального класу - це як би все в ньому Object. Будь ласка, виправте мене, якщо я помиляюся .)

Як було сказано в марці, типи не підлягають повторенню, що є проблемою в наступному випадку:

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 викидає виняток із заданим значенням, яке вловлює застереження.

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

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

Це не дозволено, оскільки тип у пункті вилову не підлягає повторенню. Під час написання цього запису компілятор 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>;
}

Те, що застереження про помилку не вдалося б змінити для генериків, не переосмислюється - це не привід для цього. Компілятор може просто заборонити конкретні загальні типи, які розширюють Throwable або забороняють генеричні дані в рамках застережень.

Загальні параметри перевіряються під час компіляції на предмет правильності типу. Інформація про загальний тип видаляється в процесі, який називається стиранням типу . Наприклад, 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");
}

Через стирання типу , час виконання не буде знати, який блок лову потрібно виконати.

Тому це помилка часу компіляції, якщо загальний клас є прямим або непрямим підкласом Throwable.

Джерело: Проблеми зі стиранням типу

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

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

Як зазначаєте, параметризація - це лише синтаксичний цукор. Однак компілятор намагається забезпечити, щоб параметризація залишалася послідовною у всіх посиланнях на об'єкт в області компіляції. У випадку винятку компілятор не може гарантувати, що MyException викидається лише з області, яку він обробляє.