Как работает exception handling в Kotlin? Опишите нюансы, отличие от Java, обработку checked/unchecked исключений, 'try', 'catch', 'finally', propagation и best practices. Приведите пример.

Ответ.

Kotlin реализует обработку исключений (exception handling) схоже с Java, но с важными отличиями. В Kotlin используются знакомые конструкции try, catch, и finally, однако принципиальное отличие — в Kotlin отсутствуют checked exceptions. Это значит, что все исключения (ошибки времени выполнения) считаются unchecked — их не требуется объявлять в сигнатуре функции и явно перехватывать.

Основные моменты:

• try/catch/finally блоки позволяют перехватывать и обрабатывать исключения. Блок finally выполняется всегда, даже если выброшено исключение.
• Отличие от Java: в Kotlin все исключения unchecked. Это упрощает синтаксис, но требует внимательного подхода к error handling.
• Kotlin поддерживает "return value" у блока try, т.е. try можно использовать как выражение, возвращая результат.
• Новые idioms: рекомендуется избегать использования try/catch для flow-control — используйте их только для truly exceptional situations.

fun parseIntOrNull(str: String): Int? = try {
    str.toInt()
} catch (e: NumberFormatException) {
    null
}

Best practices:

• Не используется для управления логикой (flow control).
• Используйте "resource management" с помощью use для автозакрытия (например, файлов).
• Не заглушайте исключения пустым catch.

Вопрос с подвохом.

В Kotlin надо ли указывать в сигнатуре функции, какие исключения она выбрасывает (как в Java — через throws)?

Правильный ответ: Нет, в Kotlin отсутствует механизм checked exceptions. Все исключения — unchecked. Не существует синтаксиса throws в сигнатуре функции (Исключение — аннотация @Throws для compatibility с Java, только для interop).

Примеры реальных ошибок из-за незнания тонкостей темы.

---

История

На проекте мигрировали Java-код с использованием checked exceptions (например, IOException). После миграции на Kotlin разработчик забыл обработать исключение при работе с файлами — приложение начало крашиться на реальных файлах, потому что никто не обрабатывал IO-ошибки, считая, что компилятор предупредит, как в Java.

---

История

Один из членов команды ошибочно использовал try/catch для flow-control и замедлил работу парсинга логов (ловил NumberFormatException для каждой невалидной строки — performance резко просел на большом объёме данных).

---

История

В проекте для JVM через Kotlin вызывался Java-код, который объявлял checked exceptions (throws). Kotlin-код не обрабатывал исключения, считая, что "всё unchecked" — в результате критическая ошибка ушла незамеченной вплоть до продуктивного инцидента.