Когда Java представила проверенные исключения - когда компилятор следит за тем, чтобы большинство исключений либо перехватывалось, либо объявлялось как выброшенное, - это была довольно новая идея. Java был гораздо более безопасным языком, чем большинство его предшественников: все поведение определено и согласовано на всех платформах, а также множество функций, предназначенных для предотвращения сбоев, неожиданного поведения или хрупкого кодирования. Таким образом, проверенные исключения хорошо вписывались в философию языка.
Но за прошедшие годы многие люди пришли к выводу, что проверенные исключения были ошибкой. Я не совсем уверен, но вот некоторые из причин:
Они многословны. Обычно методы включают много try… catch блоков и / или для объявления многих исключений. Кроме того, если существует 6 уровней вызова метода между тем, где выброшено исключение и где оно перехвачено, исключение нужно будет объявить с помощью 5 методов.
Kotlin избавляется от большей части стандартного шаблона Java и устраняетс проверенными исключениями вписывается в это.
Они поощряют плохие практики :
- Попытка обработать исключения в неправильном месте, т.е. на неправильном уровне абстракции, где ничего полезного сделать нельзя.
- Бессмысленные
catch блоки (особенно опасные, которые ничего не делают, кроме регистрации ошибок). - Перехват / объявление
Exceptionвместо определенных подтипов. - Обман путем оборачивания отмеченных исключений в непроверенные, такие как
RuntimeException.
Они увеличивают связь между модулями. Если вы используете библиотечный метод, который добавляет новое исключение, то весь код, вызывающий этот метод, должен быть обновлен для его обработки или повторного выброса.
Онитребовать исключения для перевода между различными уровнями абстракции. (Например, уровню доступа к БД может потребоваться преобразовать исключение тайм-аута сокета в исключение, недоступное для базы данных.) Это утомительно, но необходимо, чтобы избежать раскрытия деталей реализации.
Они плохо работают с наследованием. Если метод, который вы реализуете / переопределяете, не объявлен, чтобы выдать определенное проверенное исключение, то ваша реализациятакже не может его выбросить.
Они плохо работают с лямбдами. В Java лямбды реализованы с использованием интерфейсов Single-Abstract-Method и т. д. эти методы должны либо объявлять возможное исключение (в этом случае каждое использование должно обрабатывать или объявлять его), либо лямбда-тело должно перехватить исключение. Оба варианта значительно увеличивают концептуальный вес, а также код, необходимый для использования лямбд, разрушая краткость, которая является одним из их основных преимуществ.
Реализация Kotlin довольно схожа (хотя она использует свои собственные KFunction интерфейсы)и будет страдать от тех же проблем.
При всех этих проблемах ясно, что проверенные исключения в лучшем случае являются смешанным благословением. И я понимаю, почему Котлин покончил с ними.
Я действительно беспокоюсь, что это может привести к тому, что программы станут менее надежными (и менее хорошо документированными). Но за два года, что я использовал Kotlin, я не видел ни одного очевидного случая этого. Так что я пока удерживаюсь от суждения: -)
(см. Также этот вопрос.)
Что касается того, как рассматривать ваш конкретный случай, яПредложите вам сделать то же самое, что и если бы Kotlin проверил исключения: посмотрите, какие исключения может вызвать метод, который вы вызываете, выясните, как / где лучше всего их обработать, и обработайте! Тот факт, что Котлин не не заставляет вас делать это, не означает, что это не очень хорошая идея!