Исключения и Result — бесплатный тест онлайн

Вопрос 1 из 20

Какое изменение лучше всего защищает границу «Цепочка Result»?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun main() {
    val result = runCatching { "7x".toInt() }
        .map { it * 2 }
        .getOrElse { -1 }
    println(result)
}

Зафиксировать текущее поведение регрессионным тестом: Исключение выйдет наружу: runCatching перехватывает только checked-исключения. Передать ответственность владельцу вызова, предполагая, что будет выведено `14`, потому что toInt читает числовой префикс. Обрабатывать ожидаемые ошибки близко к границе и не заворачивать большие блоки, где можно случайно скрыть дефект программирования. Добавить локальную обработку результата, потому что будет выведено `0`, поскольку map получает значение по умолчанию. Сохранить API и считать достаточным условие: Код не компилируется: Result нельзя преобразовывать через map.

Вопрос 2 из 20

Какой контрпример точнее всего показывает границу «Сохранение cause и контекста»?

Проверить границу полезности утверждения: Она делает исключение проверяемым компилятором Kotlin. Сообщение не должно раскрывать секретный путь, токен или персональные данные, даже если они полезны локальной отладке. Воспроизвести редкий сценарий, где она гарантирует повторное чтение файла после создания IllegalStateException. Добавить граничный тест на утверждение: Она превращает ошибку ввода-вывода в успешное пустое значение. Отдельно воспроизвести случай, в котором она удаляет исходную трассировку, чтобы сообщение стало короче.

Вопрос 3 из 20

Что появится в выводе примера «Значение выражения try»?

// Проследите фактическое выполнение без изменения кода.
fun parse(s: String): Int = try {
    s.toInt()
} catch (_: NumberFormatException) {
    -1
}

fun main() = println(parse("12x"))

Исключение выйдет наружу: `toInt` выбрасывает не NumberFormatException. Будет выведено `-1`: `try` возвращает значение выбранной ветви `catch`. Будет выведено `0`, потому что catch не может возвращать значение. Код не компилируется без `finally`. Будет выведено `12`, поскольку `toInt` игнорирует хвост строки.

Вопрос 4 из 20

Почему пример «Исключение с контекстом» даёт именно такой результат?

// На ревью требуется объяснить причину поведения.
class InvalidAge(val supplied: Int) : IllegalArgumentException("age=$supplied")
fun register(age: Int) {
    if (age !in 0..130) throw InvalidAge(age)
}
fun main() {
    try { register(200) } catch (e: InvalidAge) { println(e.supplied) }
}

Семантика фрагмента приводит к тому, что она напечатает `0`, потому что свойства исключения не сохраняются после throw. Объяснение опирается на утверждение: Будет напечатано сообщение `age=200`, а не число, независимо от тела catch. Причину поведения формулируют так: Код не компилируется: классы исключений не могут иметь свойства. Пользовательский тип исключения полезен, когда вызывающему коду нужно отличить причину и получить структурированный контекст. Поведение связывают с правилом: Исключение не будет перехвачено, так как базовый класс IllegalArgumentException.

Вопрос 5 из 20

Для «Сохранение cause и контекста» предлагают правку: Указать операцию и безопасный идентификатор ресурса, передать `cause`, а журналировать один раз там, где принято окончательное решение. Какой компромисс нельзя пропустить?

Граница полезности решения описывается условием: Она удаляет исходную трассировку, чтобы сообщение стало короче. Богатый контекст ускоряет расследование, но чрезмерная упаковка раздувает трассировку и может скрыть исходный тип ошибки. Цена упрощения проявится, если она делает исключение проверяемым компилятором Kotlin. Главный риск формулируют так: Она гарантирует повторное чтение файла после создания IllegalStateException. Главная цена решения — необходимость учитывать, что она превращает ошибку ввода-вывода в успешное пустое значение.

Вопрос 6 из 20

Какое правило определяет поведение фрагмента «Значение выражения try»?

// На ревью требуется объяснить причину поведения.
fun parse(s: String): Int = try {
    s.toInt()
} catch (_: NumberFormatException) {
    -1
}

fun main() = println(parse("12x"))

`try` в Kotlin является выражением; `finally` выполняется, но его значение не определяет результат `try`. Причина результата в том, что будет выведено `0`, потому что catch не может возвращать значение. Поведение связывают с правилом: Код не компилируется без `finally`. Контракт здесь понимают так: Будет выведено `12`, поскольку `toInt` игнорирует хвост строки. Семантика фрагмента приводит к тому, что исключение выйдет наружу: `toInt` выбрасывает не NumberFormatException.

Вопрос 7 из 20

Какую точечную правку стоит принять на ревью фрагмента «Исключение с контекстом»?

// Сохраните назначение фрагмента, но укрепите его контракт.
class InvalidAge(val supplied: Int) : IllegalArgumentException("age=$supplied")
fun register(age: Int) {
    if (age !in 0..130) throw InvalidAge(age)
}
fun main() {
    try { register(200) } catch (e: InvalidAge) { println(e.supplied) }
}

Передать ответственность владельцу вызова, предполагая, что будет напечатано сообщение `age=200`, а не число, независимо от тела catch. Обернуть операцию проверкой и не менять основной контракт: Код не компилируется: классы исключений не могут иметь свойства. Оставить структуру прежней, документировав утверждение: Исключение не будет перехвачено, так как базовый класс IllegalArgumentException. Передавать исходную причину в `cause`, не терять значимые поля и не использовать исключения как перечень обычных состояний. Вынести участок в отдельный метод, считая верным следующее: Она напечатает `0`, потому что свойства исключения не сохраняются после throw.

Вопрос 8 из 20

Где поведение «Цепочка Result» требует отдельной проверки?

Отдельно проверить предположение, что будет выведено `0`, поскольку map получает значение по умолчанию. Без осторожности `runCatching` может поймать `CancellationException` в корутине и нарушить кооперативную отмену. Проверить соседний случай: Исключение выйдет наружу: runCatching перехватывает только checked-исключения. Проверить границу полезности утверждения: Будет выведено `14`, потому что toInt читает числовой префикс. Добавить регрессию на гипотезу: Код не компилируется: Result нельзя преобразовывать через map.

Вопрос 9 из 20

Что изменить в «Значение выражения try», чтобы скрытое допущение стало явным контрактом?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun parse(s: String): Int = try {
    s.toInt()
} catch (_: NumberFormatException) {
    -1
}

fun main() = println(parse("12x"))

Перенести проверку в вызывающий код, исходя из того, что будет выведено `0`, потому что catch не может возвращать значение. Оставить реализацию без изменений и закрепить тестом предположение: Исключение выйдет наружу: `toInt` выбрасывает не NumberFormatException. Не кодировать ожидаемую ошибку произвольным числом, а вернуть nullable или предметный результат с причиной. Обернуть операцию проверкой и не менять основной контракт: Будет выведено `12`, поскольку `toInt` игнорирует хвост строки. Оставить структуру прежней, документировав утверждение: Код не компилируется без `finally`.

Вопрос 10 из 20

Где упрощённое объяснение «Исключение с контекстом» перестаёт работать?

Воспроизвести редкий сценарий, где код не компилируется: классы исключений не могут иметь свойства. Отдельно воспроизвести случай, в котором исключение не будет перехвачено, так как базовый класс IllegalArgumentException. Kotlin не различает checked и unchecked исключения в типовой системе; Java-потребителям может понадобиться `@Throws`. Добавить тест на состояние, при котором будет напечатано сообщение `age=200`, а не число, независимо от тела catch. Добавить граничный тест на утверждение: Она напечатает `0`, потому что свойства исключения не сохраняются после throw.

Вопрос 11 из 20

Какой риск не исчезает после правки «Цепочка Result»: Обрабатывать ожидаемые ошибки близко к границе и не заворачивать большие блоки, где можно случайно скрыть дефект программирования?

Главный риск формулируют так: Исключение выйдет наружу: runCatching перехватывает только checked-исключения. После внедрения придётся исходить из того, что будет выведено `0`, поскольку map получает значение по умолчанию. Граница полезности решения описывается условием: Будет выведено `14`, потому что toInt читает числовой префикс. Result делает цепочку успеха и ошибки явной в коде, но потеря доменного типа ошибки приводит к обработке только по Throwable. Цена упрощения проявится, если код не компилируется: Result нельзя преобразовывать через map.

Вопрос 12 из 20

Что важного сохраняет такая повторная упаковка ошибки?

// Проследите фактическое выполнение без изменения кода.
fun load(path: String): String = try {
    java.io.File(path).readText()
} catch (e: java.io.IOException) {
    throw IllegalStateException("Не удалось прочитать $path", e)
}

Она превращает ошибку ввода-вывода в успешное пустое значение. Она удаляет исходную трассировку, чтобы сообщение стало короче. Она добавляет контекст и сохраняет исходное `IOException` как `cause`. Она делает исключение проверяемым компилятором Kotlin. Она гарантирует повторное чтение файла после создания IllegalStateException.

Вопрос 13 из 20

Какой риск не исчезает после правки «Исключение с контекстом»: Передавать исходную причину в `cause`, не терять значимые поля и не использовать исключения как перечень обычных состояний?

Практическое ограничение подхода: Будет напечатано сообщение `age=200`, а не число, независимо от тела catch. Отдельный тип улучшает обработку и журналирование, но слишком подробная иерархия превращает ошибки в хрупкий публичный API. Граница полезности решения описывается условием: Она напечатает `0`, потому что свойства исключения не сохраняются после throw. Цена упрощения проявится, если код не компилируется: классы исключений не могут иметь свойства. После внедрения придётся исходить из того, что исключение не будет перехвачено, так как базовый класс IllegalArgumentException.

Вопрос 14 из 20

Каков результат?

// Проследите фактическое выполнение без изменения кода.
fun main() {
    val result = runCatching { "7x".toInt() }
        .map { it * 2 }
        .getOrElse { -1 }
    println(result)
}

Будет `-1`: ошибка останется в `Result`, `map` пропустится, а `getOrElse` вернёт запасное значение. Исключение выйдет наружу: runCatching перехватывает только checked-исключения. Будет выведено `0`, поскольку map получает значение по умолчанию. Код не компилируется: Result нельзя преобразовывать через map. Будет выведено `14`, потому что toInt читает числовой префикс.

Вопрос 15 из 20

Какое правило определяет поведение фрагмента «Сохранение cause и контекста»?

// На ревью требуется объяснить причину поведения.
fun load(path: String): String = try {
    java.io.File(path).readText()
} catch (e: java.io.IOException) {
    throw IllegalStateException("Не удалось прочитать $path", e)
}

Поведение связывают с правилом: Она гарантирует повторное чтение файла после создания IllegalStateException. Причина результата в том, что она превращает ошибку ввода-вывода в успешное пустое значение. Контекст добавляют на границе абстракции, сохраняя исходную причину; одно и то же исключение не следует журналировать на каждом уровне. Причину поведения формулируют так: Она делает исключение проверяемым компилятором Kotlin. Семантика фрагмента приводит к тому, что она удаляет исходную трассировку, чтобы сообщение стало короче.

Вопрос 16 из 20

На каком входе или состоянии граница «Значение выражения try» становится заметной?

Считать опасной границей ситуацию, где исключение выйдет наружу: `toInt` выбрасывает не NumberFormatException. `return` или новое исключение из `finally` перекрывает обычный результат и исходную ошибку, поэтому такой код опасен. Добавить регрессию на гипотезу: Будет выведено `0`, потому что catch не может возвращать значение. Проверить крайний ввод, при котором код не компилируется без `finally`. Зафиксировать сценарий, где ожидается: Будет выведено `12`, поскольку `toInt` игнорирует хвост строки.

Вопрос 17 из 20

Какой принцип лежит в основе поведения «Цепочка Result»?

// На ревью требуется объяснить причину поведения.
fun main() {
    val result = runCatching { "7x".toInt() }
        .map { it * 2 }
        .getOrElse { -1 }
    println(result)
}

Механика примера описывается утверждением: Будет выведено `0`, поскольку map получает значение по умолчанию. Такой результат объясняют тем, что будет выведено `14`, потому что toInt читает числовой префикс. `runCatching` упаковывает успешное значение или пойманный `Throwable` в `Result`; последующие операции разделяют эти пути. Из правил языка или API следует, что исключение выйдет наружу: runCatching перехватывает только checked-исключения. Причина результата в том, что код не компилируется: Result нельзя преобразовывать через map.

Вопрос 18 из 20

Что изменить в «Сохранение cause и контекста», чтобы скрытое допущение стало явным контрактом?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun load(path: String): String = try {
    java.io.File(path).readText()
} catch (e: java.io.IOException) {
    throw IllegalStateException("Не удалось прочитать $path", e)
}

Вынести участок в отдельный метод, считая верным следующее: Она удаляет исходную трассировку, чтобы сообщение стало короче. Оставить структуру прежней, документировав утверждение: Она гарантирует повторное чтение файла после создания IllegalStateException. Обернуть операцию проверкой и не менять основной контракт: Она делает исключение проверяемым компилятором Kotlin. Указать операцию и безопасный идентификатор ресурса, передать `cause`, а журналировать один раз там, где принято окончательное решение. Перенести проверку в вызывающий код, исходя из того, что она превращает ошибку ввода-вывода в успешное пустое значение.

Вопрос 19 из 20

Решение для «Значение выражения try»: Не кодировать ожидаемую ошибку произвольным числом, а вернуть nullable или предметный результат с причиной. Что в нём остаётся не бесплатным?

Исключение удобно для редкого нештатного пути, но как обычный протокол разбора оно ухудшает ясность и диагностику. Обратная сторона изменения состоит в том, что исключение выйдет наружу: `toInt` выбрасывает не NumberFormatException. Главная цена решения — необходимость учитывать, что будет выведено `12`, поскольку `toInt` игнорирует хвост строки. После правки останется ограничение: Код не компилируется без `finally`. Решение оправдано лишь при условии: Будет выведено `0`, потому что catch не может возвращать значение.

Вопрос 20 из 20

Что выведет фрагмент «Исключение с контекстом»?

// Проследите фактическое выполнение без изменения кода.
class InvalidAge(val supplied: Int) : IllegalArgumentException("age=$supplied")
fun register(age: Int) {
    if (age !in 0..130) throw InvalidAge(age)
}
fun main() {
    try { register(200) } catch (e: InvalidAge) { println(e.supplied) }
}

Она напечатает `200`: пользовательское исключение хранит контекст и перехватывается по собственному типу. Исключение не будет перехвачено, так как базовый класс IllegalArgumentException. Код не компилируется: классы исключений не могут иметь свойства. Будет напечатано сообщение `age=200`, а не число, независимо от тела catch. Она напечатает `0`, потому что свойства исключения не сохраняются после throw.