Краткий ответ

Java запрещает обобщённым классам прямо или косвенно наследовать Throwable, потому что параметры типов стираются, а механизм catch работает с реальными классами исключений во время выполнения. После стирания разные варианты одного параметризованного исключения имели бы один и тот же runtime-класс, поэтому JVM не смогла бы различать их по аргументам типа.

Исторический контекст

Generics появились в Java с расчётом на сохранение совместимости существующего кода и JVM. Для этого Java использует в основном стирание типов: параметры типов участвуют в проверке компилятором, но обычно не сохраняются как часть runtime-типа объекта.

Механизм исключений JVM существовал до generics и сопоставляет выброшенный объект с обработчиком по классу исключения. Он не использует аргументы параметров типов из сигнатуры generics.

Постановка проблемы

Предположим, существуют варианты Ошибка<String> и Ошибка<Integer>. На уровне исходного кода они выглядят как разные параметризации, но после стирания оба имеют один класс Ошибка.

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

Подробное решение

Правило Java запрещает классу, параметризованному типом, прямо или косвенно наследовать Throwable. Поэтому следующий класс недопустим:

class Failure<T> extends Exception {
    private final T value;
    Failure(T value) { this.value = value; }
}

Проблема не в поле value, а именно в наследовании от Exception. После стирания Failure<String> и Failure<Integer> стали бы экземплярами одного runtime-класса Failure. Сигнатура generics может сохраняться в метаданных класса, но JVM не использует её для выбора обработчика исключения.

Нельзя было бы также надёжно выразить обработчики вроде catch (Failure<String>) и catch (Failure<Integer>): такие типы не являются различимыми runtime-типами. Поэтому ограничение введено на уровне объявления класса, а не только на уровне конкретного catch.

Обычно применяют обычное, непараметризованное исключение и хранят в нём контекст: идентификатор, имя поля, код ошибки или объект полезной нагрузки. Если тип полезной нагрузки критичен для безопасности, его проверяют явно либо используют отдельные непараметризованные классы исключений.

У generic-метода может быть параметр типа с верхней границей Throwable и объявление throws T: это другой механизм. Метод не создаёт параметризованный подкласс Throwable; параметр типа лишь описывает тип исключения, который уже существует как обычный класс.

Ситуация из практики

В библиотеке валидации хотели объявить единый тип ValidationException<T>, где T описывает тип ошибочного значения. Это позволило бы удобно хранить типизированную полезную нагрузку, но создало бы запрещённую и неразличимую иерархию исключений.

Первый вариант — сделать отдельные классы StringValidationException, DateValidationException и другие. Он обеспечивает точное сопоставление в catch, но приводит к росту числа классов и усложняет расширение библиотеки.

Второй вариант — использовать одно ValidationException с полем типа Object или с общей непараметризованной моделью ошибки. Он сохраняет простую иерархию и совместим с JVM, но требует проверки типа полезной нагрузки в коде обработчика.

Практически выбирают второй вариант, если обработка зависит прежде всего от кода или категории ошибки. Если разные ошибки действительно требуют разной логики обработки, лучше создать отдельные обычные классы исключений: это явно отражает runtime-семантику и не зависит от стёртых параметров типов.

Что кандидаты часто упускают

Можно ли различать параметризации исключения через instanceof?

Нет. Проверка instanceof работает с reifiable-типами, то есть с типами, представление которых доступно во время выполнения. Failure<String> и Failure<Integer> после стирания имеют один класс Failure, поэтому проверка аргумента типа невозможна. Можно проверить только сам непараметризованный класс, а содержимое полезной нагрузки проверять отдельно.
Разрешено ли generic-методу объявлять throws T, если T ограничен типом Throwable?

Да, это разрешено, поскольку параметр T не создаёт новый класс исключения. Например, метод может объявить типовой параметр T extends Exception и передавать вызывающему коду исключение типа T. Компилятор учитывает это объявление при проверке checked exceptions, но JVM всё равно работает с фактическим обычным классом исключения.
Почему нельзя решить проблему сохранением аргумента типа в поле исключения?

Поле может хранить Class<T> или объект полезной нагрузки и тем самым позволить выполнить дополнительную проверку после перехвата. Однако это не меняет класс самого исключения: механизм catch по-прежнему видит только один runtime-класс. Такой подход подходит для ручной маршрутизации ошибок, но не заменяет разные типы исключений и не позволяет JVM автоматически выбрать обработчик по T.