Почему конструкторы сканера с аргументом кодировки String не генерируют исключение UnsupportedEncodingException?

Question

Конструкторы почти всех классов из java.io и Formatter всегда выбрасывают флажок UnsupportedEncodingException, если String encoding является аргументом конструктора.

Но Scanner совершенно другой - он выбрасывает только runtine IllegalArgumentException, если аргумент кодирования введен с ошибкой / неверен.

Кажется, единственный конструктор класса сканера, который не выбрасывает отмеченный UnsupportedEncodingException во всех java API (с String, кодирующим аргумент конструктора), выбрасывая только исключительную ситуацию IllegalArgumentException.

Это почему?Просто причуды дизайна / совместимости или какие-то глубокие рассуждения за этим?

Answer 1

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

Я думаю, что решение было принято намеренно.

Исключение UnsupportedEncodingException немного аномально:

• Это подтип IOException, где кодирование / декодирование фактически ортогонально вводу / выводу: рассмотрим конструктор String(byte[], String).

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

  1. Если на самом деле выдается UnsupportedEncodingException, это, скорее всего, результат ошибки программирования, а не ошибки, с которой ваше приложение может быть в состоянии восстановиться.

  2. Один из наиболее распространенных сценариев использования - дать строку «UTF-8» в качестве имени кодировки.Спецификации Java гарантируют, что UTF-8 всегда будет поддерживаться совместимой JVM, однако, поскольку исключение проверено, нам все равно нужно написать обработчик ... для сбоя, который не может произойти.

Учитывая эти проблемы, я думаю, дизайнеры решили, что лучше не использовать UnsupportedEncodingException в Scanner, а использовать исключение без проверки для случая, когда запрошенная кодировка не поддерживается.