Option, Either и Try — бесплатный тест онлайн

Вопрос 1 из 20

В теме «Отсутствие значения» какая из перечисленных гарантий принадлежит именно показанному механизму?

val found = Map("a" -> 1).get("b")
println(found.fold(0)(_ * 10))

`Option` показывает возможное отсутствие значения: `Some` содержит данные, `None` не содержит их. Порядок ветвей и шаблонов несущественен: перед выполнением Scala автоматически переставляет их от частных к общим. Компилятор откладывает выбор типа до первого использования значения, поэтому объявленная форма выражения здесь ничего не ограничивает. `Either[L, R]` хранит либо ошибку слева, либо успешное значение справа и по умолчанию преобразует правую сторону. `Map` и `flatMap` позволяют последовательно строить вычисление в одном контексте, прекращая цепочку на `None`, `Left` или `Failure`.

Вопрос 2 из 20

Для темы «Отсутствие значения» обычный пример прошёл, затем изменились условия использования. Какой риск нужно проверить первым?

// Дополнительный контекст: После рефакторинга код по-прежнему компилируется, однако его статический тип стал шире.
val found = Map("a" -> 1).get("b")
println(found.fold(0)(_ * 10))

Риск возникает только при `var`; `val`, `case class` и неизменяемая коллекция полностью исключают скрытое состояние и ошибочный контракт. Если две ветви компилируются по отдельности, их общий тип обязательно сохранит методы обеих ветвей. Смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. Сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. Вызов `.get` возвращает риск исключения и уничтожает преимущество явного моделирования отсутствия.

Вопрос 3 из 20

При исправлении темы «Отсутствие значения» команда сравнивает несколько правок. Какая из них делает допущение явным и проверяемым?

val found = Map("a" -> 1).get("b")
println(found.fold(0)(_ * 10))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Заменить `None` общей изменяемой заглушкой и возвращать её всем вызывающим участкам. Обрабатывайте `Option` через `fold`, `map`, pattern matching или осмысленное значение по умолчанию. Добавить общий `case _` и возвращать нейтральное значение: так новые варианты модели не будут останавливать сборку. Выберите один тип результата на уровне операции и преобразуйте внешние ошибки в него на входной границе. Применяйте `Try` на синхронной границе API, а асинхронные ошибки обрабатывайте средствами `Future` или эффекта.

Вопрос 4 из 20

В контракте темы «Отсутствие значения» фрагмент вынесли из локальной функции в общий модуль и добавили новый вариант входных данных. Какой анализ пригоден для публичного API?

Опираться на семантику «`map` и `flatMap` позволяют последовательно строить вычисление в одном контексте, прекращая цепочку на `None`, `Left` или `Failure`», но отдельно проверять ограничение «вызов `.get` возвращает риск исключения и уничтожает преимущество явного моделирования отсутствия». Опираться на семантику «`Option` показывает возможное отсутствие значения: `Some` содержит данные, `None` не содержит их», но отдельно проверять ограничение «смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок». Опираться на семантику «`Option` показывает возможное отсутствие значения: `Some` содержит данные, `None` не содержит их», но отдельно проверять ограничение «успешная обработка одного значения подтверждает совместимость всех вариантов модели». Опираться на семантику «`Option` показывает возможное отсутствие значения: `Some` содержит данные, `None` не содержит их», но отдельно проверять ограничение «вызов `.get` возвращает риск исключения и уничтожает преимущество явного моделирования отсутствия». Опираться на семантику «`Either[L, R]` хранит либо ошибку слева, либо успешное значение справа и по умолчанию преобразует правую сторону», но отдельно проверять ограничение «сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения».

Вопрос 5 из 20

Какой критерий готовности по теме «Отсутствие значения» действительно поймает повтор прежнего дефекта?

`Option` показывает возможное отсутствие значения: `Some` содержит данные, `None` не содержит их. Ограничиться ручным запуском без автоматической регрессии. Обрабатывайте `Option` через `fold`, `map`, pattern matching или осмысленное значение по умолчанию. В проверке воспроизвести ситуацию: вызов `.get` возвращает риск исключения и уничтожает преимущество явного моделирования отсутствия. Обрабатывайте `Option` через `fold`, `map`, pattern matching или осмысленное значение по умолчанию. В проверке воспроизвести ситуацию: смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. Применяйте `Try` на синхронной границе API, а асинхронные ошибки обрабатывайте средствами `Future` или эффекта. В проверке воспроизвести ситуацию: вызов `.get` возвращает риск исключения и уничтожает преимущество явного моделирования отсутствия. В теме «Отсутствие значения» исправить один показанный вызов по рекомендации «Выберите один тип результата на уровне операции и преобразуйте внешние ошибки в него на входной границе». Общий контракт и прежнюю границу отдельно не воспроизводить.

Вопрос 6 из 20

В теме «Ошибки как данные» как сформулировать семантику примера так, чтобы она сохранилась после переименования переменных?

def parse(s: String): Either[String, Int] = s.toIntOption.toRight("not a number")
println(parse("12").map(_ + 1))

`Option` показывает возможное отсутствие значения: `Some` содержит данные, `None` не содержит их. `Try` переводит обычное синхронное исключение из группы `NonFatal` в `Failure`, а успешный результат — в `Success`. Порядок ветвей и шаблонов несущественен: перед выполнением Scala автоматически переставляет их от частных к общим. Успешная компиляция означает, что замена конкретного типа на `Any` не изменит доступные операции и результат программы. `Either[L, R]` хранит либо ошибку слева, либо успешное значение справа и по умолчанию преобразует правую сторону.

Вопрос 7 из 20

Какой сценарий отличает реальную гарантию «Ошибки как данные» от случайного успеха?

// Дополнительный контекст: Публичную сигнатуру слегка изменили, но большая часть вызывающего кода осталась прежней.
def parse(s: String): Either[String, Int] = s.toIntOption.toRight("not a number")
println(parse("12").map(_ + 1))

Пограничное значение будет автоматически отклонено до выполнения, даже если код явно делает сужающее преобразование или приведение. Смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. Сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. Локальное изменение сигнатуры не способно повлиять на поиск перегрузки, given или вывод типа в вызывающем коде. Вызов `.get` возвращает риск исключения и уничтожает преимущество явного моделирования отсутствия.

Вопрос 8 из 20

При исправлении темы «Ошибки как данные» какой вариант не переносит проблему в вызывающий код?

def parse(s: String): Either[String, Int] = s.toIntOption.toRight("not a number")
println(parse("12").map(_ + 1))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Ввести неявное преобразование между типами, чтобы вызывающий код продолжил компилироваться без явной миграции. Спрятать несовместимость за `asInstanceOf`, сохранив прежнюю сигнатуру и добавив тест только для рабочего примера. Опишите ошибки закрытым типом и преобразуйте их в текст только на границе интерфейса. Выберите один тип результата на уровне операции и преобразуйте внешние ошибки в него на входной границе. Применяйте `Try` на синхронной границе API, а асинхронные ошибки обрабатывайте средствами `Future` или эффекта.

Вопрос 9 из 20

В контракте темы «Ошибки как данные» какой вариант не теряет существенную часть технической картины?

`Either[L, R]` хранит либо ошибку слева, либо успешное значение справа и по умолчанию преобразует правую сторону. При этом учитывать: сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. `Option` показывает возможное отсутствие значения: `Some` содержит данные, `None` не содержит их. При этом учитывать: вызов `.get` возвращает риск исключения и уничтожает преимущество явного моделирования отсутствия. `Either[L, R]` хранит либо ошибку слева, либо успешное значение справа и по умолчанию преобразует правую сторону. При этом учитывать: смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. `Either[L, R]` хранит либо ошибку слева, либо успешное значение справа и по умолчанию преобразует правую сторону. При этом учитывать: результат одного измерения можно считать устойчивой характеристикой производительности. `Try` переводит обычное синхронное исключение из группы `NonFatal` в `Failure`, а успешный результат — в `Success`. При этом учитывать: сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения.

Вопрос 10 из 20

При проверке темы «Ошибки как данные» что лучше не оставлять только в устной договорённости?

Опишите ошибки закрытым типом и преобразуйте их в текст только на границе интерфейса. В проверке воспроизвести ситуацию: сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. `Either[L, R]` хранит либо ошибку слева, либо успешное значение справа и по умолчанию преобразует правую сторону. Проверить один объект и не рассматривать разделяемое состояние. В теме «Ошибки как данные» исправить один показанный вызов по рекомендации «Применяйте `Try` на синхронной границе API, а асинхронные ошибки обрабатывайте средствами `Future` или эффекта». Общий контракт и прежнюю границу отдельно не воспроизводить. Опишите ошибки закрытым типом и преобразуйте их в текст только на границе интерфейса. В проверке воспроизвести ситуацию: смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. Выберите один тип результата на уровне операции и преобразуйте внешние ошибки в него на входной границе. В проверке воспроизвести ситуацию: сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения.

Вопрос 11 из 20

Во фрагменте проверяется тема «Композиция». Какое правило точнее всего объясняет поведение кода?

val r = for
  a <- "10".toIntOption
  b <- "2".toIntOption
yield a / b
println(r)

`Try` переводит обычное синхронное исключение из группы `NonFatal` в `Failure`, а успешный результат — в `Success`. `Map` и `flatMap` позволяют последовательно строить вычисление в одном контексте, прекращая цепочку на `None`, `Left` или `Failure`. Компилятор откладывает выбор типа до первого использования значения, поэтому объявленная форма выражения здесь ничего не ограничивает. Любая конструкция, записанная через `val`, делает связанный объект неизменяемым, а все его методы — безопасными для параллельного вызова. `Option` показывает возможное отсутствие значения: `Some` содержит данные, `None` не содержит их.

Вопрос 12 из 20

Для темы «Композиция» на какой границе это решение перестаёт быть достаточным?

После первого `Some` последующие вызовы `flatMap` уже не способны вернуть `None`. Сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. Смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. Вызов `.get` возвращает риск исключения и уничтожает преимущество явного моделирования отсутствия. Локальное изменение сигнатуры не способно повлиять на поиск перегрузки, given или вывод типа в вызывающем коде.

Вопрос 13 из 20

При исправлении темы «Композиция» что следует изменить, чтобы следующий рефакторинг не вернул тот же риск?

val r = for
  a <- "10".toIntOption
  b <- "2".toIntOption
yield a / b
println(r)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Выберите один тип результата на уровне операции и преобразуйте внешние ошибки в него на входной границе. Применяйте `Try` на синхронной границе API, а асинхронные ошибки обрабатывайте средствами `Future` или эффекта. Опишите ошибки закрытым типом и преобразуйте их в текст только на границе интерфейса. Оставить публичный тип результата выведенным из тела: это позволит API автоматически подстраиваться под будущие правки. Расширить спорный тип до `Any`, а точные проверки перенести во все места использования, чтобы не менять текущую реализацию.

Вопрос 14 из 20

В контракте темы «Композиция» что следует оставить в проектном решении после этого изменения контекста?

`Try` переводит обычное синхронное исключение из группы `NonFatal` в `Failure`, а успешный результат — в `Success`. Учитывать границу: смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. `Map` и `flatMap` позволяют последовательно строить вычисление в одном контексте, прекращая цепочку на `None`, `Left` или `Failure`. Учитывать границу: прохождение happy path исключает ошибки сериализации на старых и неполных данных. `Map` и `flatMap` позволяют последовательно строить вычисление в одном контексте, прекращая цепочку на `None`, `Left` или `Failure`. Учитывать границу: сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. `Option` показывает возможное отсутствие значения: `Some` содержит данные, `None` не содержит их. Учитывать границу: вызов `.get` возвращает риск исключения и уничтожает преимущество явного моделирования отсутствия. `Map` и `flatMap` позволяют последовательно строить вычисление в одном контексте, прекращая цепочку на `None`, `Left` или `Failure`. Учитывать границу: смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок.

Вопрос 15 из 20

При проверке темы «Композиция» какой итог можно проверить автоматически или воспроизводимым примером?

В теме «Композиция» исправить один показанный вызов по рекомендации «Применяйте `Try` на синхронной границе API, а асинхронные ошибки обрабатывайте средствами `Future` или эффекта». Общий контракт и прежнюю границу отдельно не воспроизводить. Выберите один тип результата на уровне операции и преобразуйте внешние ошибки в него на входной границе. В проверке воспроизвести ситуацию: сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. Выберите один тип результата на уровне операции и преобразуйте внешние ошибки в него на входной границе. В проверке воспроизвести ситуацию: смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. `Map` и `flatMap` позволяют последовательно строить вычисление в одном контексте, прекращая цепочку на `None`, `Left` или `Failure`. Считать отсутствие исключения достаточным подтверждением контракта. Опишите ошибки закрытым типом и преобразуйте их в текст только на границе интерфейса. В проверке воспроизвести ситуацию: смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок.

Вопрос 16 из 20

В теме «Преобразование результата» что в этом примере определяется семантикой Scala, а не соглашением автора?

import scala.util.Try
val r = Try("42".toInt).map(_ / 2)
println(r)

`map` и `flatMap` позволяют последовательно строить вычисление в одном контексте, прекращая цепочку на `None`, `Left` или `Failure` `Try` переводит обычное синхронное исключение из группы `NonFatal` в `Failure`, а успешный результат — в `Success` `Either[L, R]` хранит либо ошибку слева, либо успешное значение справа и по умолчанию преобразует правую сторону Успешная компиляция означает, что замена конкретного типа на `Any` не изменит доступные операции и результат программы Порядок ветвей и шаблонов несущественен: перед выполнением Scala автоматически переставляет их от частных к общим

Вопрос 17 из 20

Для темы «Преобразование результата» после переноса кода в общий модуль проявилось скрытое допущение. Какое?

Смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. Пограничное значение будет автоматически отклонено до выполнения, даже если код явно делает сужающее преобразование или приведение. Сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. Единственное последствие ошибки здесь — менее понятное сообщение компилятора; поведение собранной программы не меняется. Использовать `Try` вокруг уже запущенного асинхронного процесса бесполезно: будущая ошибка произойдёт после выхода из блока.

Вопрос 18 из 20

Какое действие делает решение по теме «Преобразование результата» устойчивее?

import scala.util.Try
val r = Try("42".toInt).map(_ / 2)
println(r)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

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

Вопрос 19 из 20

В контракте темы «Преобразование результата» фрагмент вынесли из локальной функции в общий модуль и добавили новый вариант входных данных. Какой вывод одновременно сохраняет правило и учитывает его границу?

`Map` и `flatMap` позволяют последовательно строить вычисление в одном контексте, прекращая цепочку на `None`, `Left` или `Failure`; использовать `Try` вокруг уже запущенного асинхронного процесса бесполезно: будущая ошибка произойдёт после выхода из блока. `Either[L, R]` хранит либо ошибку слева, либо успешное значение справа и по умолчанию преобразует правую сторону; смешивание разных контекстов без явного преобразования создаёт вложенные типы и усложняет обработку ошибок. `Try` переводит обычное синхронное исключение из группы `NonFatal` в `Failure`, а успешный результат — в `Success`; использовать `Try` вокруг уже запущенного асинхронного процесса бесполезно: будущая ошибка произойдёт после выхода из блока. `Try` переводит обычное синхронное исключение из группы `NonFatal` в `Failure`, а успешный результат — в `Success`; сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. `Try` переводит обычное синхронное исключение из группы `NonFatal` в `Failure`, а успешный результат — в `Success`; если локальный вызов успешен, распределённые повторы и частичные отказы не меняют вывод.

Вопрос 20 из 20

При проверке темы «Преобразование результата» как сформулировать защиту от регрессии без расплывчатого «работает как раньше»?

Применяйте `Try` на синхронной границе API, а асинхронные ошибки обрабатывайте средствами `Future` или эффекта. В проверке воспроизвести ситуацию: сведение всех ошибок к строке теряет структуру, код причины и возможность безопасного автоматического решения. В теме «Преобразование результата» исправить один показанный вызов по рекомендации «Опишите ошибки закрытым типом и преобразуйте их в текст только на границе интерфейса». Общий контракт и прежнюю границу отдельно не воспроизводить. Применяйте `Try` на синхронной границе API, а асинхронные ошибки обрабатывайте средствами `Future` или эффекта. В проверке воспроизвести ситуацию: использовать `Try` вокруг уже запущенного асинхронного процесса бесполезно: будущая ошибка произойдёт после выхода из блока. Выберите один тип результата на уровне операции и преобразуйте внешние ошибки в него на входной границе. В проверке воспроизвести ситуацию: использовать `Try` вокруг уже запущенного асинхронного процесса бесполезно: будущая ошибка произойдёт после выхода из блока. `Try` переводит обычное синхронное исключение из группы `NonFatal` в `Failure`, а успешный результат — в `Success`. Проверить только маленький объём данных и не измерять рост затрат.