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

Вопрос 1 из 20

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

Never fail(String field, Object? value) {
  throw FormatException('Invalid $field: $value');
}
int parsePort(String text) {
  final value = int.tryParse(text);
  return value == null || value <= 0 ? fail('port', text) : value;
}

// Контекст задания: проверка семантики фрагмента.

Спорный результат «Выбрасывание исключений» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Порядок внутренних вызовов «Выбрасывание исключений» считать публичной гарантией, которую нельзя менять при рефакторинге. В теме «Выбрасывание исключений» отсутствие предупреждения анализатора считать гарантией для любого допустимого входа. Случай «исключение без полезных полей» объявить внутренней деталью «Выбрасывание исключений», даже если клиент видит иной результат. `throw` принимает любой ненулевой объект, но для предсказуемого API лучше использовать типы исключений с понятным смыслом и полезными данными.

Вопрос 2 из 20

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

Never fail(String field, Object? value) {
  throw FormatException('Invalid $field: $value');
}
int parsePort(String text) {
  final value = int.tryParse(text);
  return value == null || value <= 0 ? fail('port', text) : value;
}

// Контекст задания: выбор места исправления.

Скопировать защиту «Выбрасывание исключений» во все найденные места вызова и считать повторение единым исправлением. Выбрасывать типизированное исключение с причиной и существенным контекстом, не включая секретные данные. Перенести проверку «Выбрасывание исключений» в тестовый код, не меняя производственную реализацию. Оставить поведение «Выбрасывание исключений» прежним, но заменить сообщение об ошибке на более подробное. Скрыть сбой «Выбрасывание исключений» автоматической повторной попыткой без ограничения числа запусков.

Вопрос 3 из 20

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

Never fail(String field, Object? value) {
  throw FormatException('Invalid $field: $value');
}
int parsePort(String text) {
  final value = int.tryParse(text);
  return value == null || value <= 0 ? fail('port', text) : value;
}

// Контекст задания: анализ граничных входов.

Проверить для «Выбрасывание исключений» только самый сложный случай «исключение без полезных полей», считая остальные границы косвенно покрытыми. Автоматизировать обычный путь «Выбрасывание исключений», а случай «исключение без полезных полей» оставить в ручном чек-листе выпуска. Объединить «выбрасывание строки или случайного объекта» и «потеря предметного контекста» в один тест «Выбрасывание исключений» с общим ожидаемым исходом. Для «Выбрасывание исключений» ограничиться случаем «выбрасывание строки или случайного объекта», а остальные входы считать тем же классом отказа. Задать самостоятельные ожидания для случаев: выбрасывание строки или случайного объекта, потеря предметного контекста и исключение без полезных полей.

Вопрос 4 из 20

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

В договоре «Выбрасывание исключений» описать только успешный путь, оставив спорные входы на усмотрение реализации. Перед вызовом «Выбрасывание исключений» заставить клиента повторять валидацию, не описывая отказ самого компонента. Включить в договор «Выбрасывание исключений» конкретный способ хранения состояния вместо наблюдаемого результата. Публичная операция должна сообщать предсказуемый тип отказа, который клиент может обработать без разбора текста. Из «Выбрасывание исключений» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте.

Вопрос 5 из 20

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

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

Вопрос 6 из 20

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

Future<void> save() async {
  final file = await openFile();
  try {
    await file.write();
  } on FileSystemException catch (e, st) {
    log(e, st);
    rethrow;
  } finally {
    await file.close();
  }
}

// Контекст задания: проверка семантики фрагмента.

Порядок внутренних вызовов «Обработка и завершение после ошибок» считать публичной гарантией, которую нельзя менять при рефакторинге. `catch` обрабатывает совпавшее исключение, `on` ограничивает тип, `finally` выполняется при обычном выходе и при исключении; `rethrow` сохраняет исходную трассировку. Спорный результат «Обработка и завершение после ошибок» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Случай «ошибка внутри очистки» объявить внутренней деталью «Обработка и завершение после ошибок», даже если клиент видит иной результат. Два компилирующихся варианта «Обработка и завершение после ошибок» считать семантически взаимозаменяемыми без проверки результата.

Вопрос 7 из 20

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

Future<void> save() async {
  final file = await openFile();
  try {
    await file.write();
  } on FileSystemException catch (e, st) {
    log(e, st);
    rethrow;
  } finally {
    await file.close();
  }
}

// Контекст задания: анализ граничных входов.

Во всех спорных входах «Обработка и завершение после ошибок» проверять только отсутствие необработанного исключения, не сравнивая состояние. Автоматизировать обычный путь «Обработка и завершение после ошибок», а случай «ошибка внутри очистки» оставить в ручном чек-листе выпуска. Задать самостоятельные ожидания для случаев: совпадение `on` и `catch`, выполнение `finally`, ранний `return` и ошибка внутри очистки. Объединить «совпадение `on` и `catch`» и «выполнение `finally`» в один тест «Обработка и завершение после ошибок» с общим ожидаемым исходом. Для «Обработка и завершение после ошибок» ограничиться случаем «совпадение `on` и `catch`», а остальные входы считать тем же классом отказа.

Вопрос 8 из 20

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

Future<void> save() async {
  final file = await openFile();
  try {
    await file.write();
  } on FileSystemException catch (e, st) {
    log(e, st);
    rethrow;
  } finally {
    await file.close();
  }
}

// Контекст задания: выбор места исправления.

Перехватывать только ожидаемые типы, а очистку выполнять в `finally`, не скрывая исходную ошибку новой. Перенести проверку «Обработка и завершение после ошибок» в тестовый код, не меняя производственную реализацию. Скрыть сбой «Обработка и завершение после ошибок» автоматической повторной попыткой без ограничения числа запусков. Скопировать защиту «Обработка и завершение после ошибок» во все найденные места вызова и считать повторение единым исправлением. Оставить поведение «Обработка и завершение после ошибок» прежним, но заменить сообщение об ошибке на более подробное.

Вопрос 9 из 20

Ручная проверка по теме «Обработка и завершение после ошибок» прошла. Как превратить её в полезную автоматическую регрессию?

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

Вопрос 10 из 20

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

Обработка должна сохранять первичную причину и гарантировать завершение обязательной очистки. Включить в договор «Обработка и завершение после ошибок» конкретный способ хранения состояния вместо наблюдаемого результата. Перед вызовом «Обработка и завершение после ошибок» заставить клиента повторять валидацию, не описывая отказ самого компонента. В договоре «Обработка и завершение после ошибок» описать только успешный путь, оставив спорные входы на усмотрение реализации. Из «Обработка и завершение после ошибок» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте.

Вопрос 11 из 20

Несколько мест использования повторяют одну и ту же защиту. Какая правка должна стать единой для темы «Собственные исключения»?

final class InvalidOrder implements Exception {
  InvalidOrder(this.orderId, this.reason);
  final String orderId;
  final String reason;
  @override String toString() => 'InvalidOrder($orderId, $reason)';
}

// Контекст задания: выбор места исправления.

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

Вопрос 12 из 20

Код прошёл демонстрационный пример, но границы не разобраны. Что нужно проверить отдельно в теме «Собственные исключения»?

final class InvalidOrder implements Exception {
  InvalidOrder(this.orderId, this.reason);
  final String orderId;
  final String reason;
  @override String toString() => 'InvalidOrder($orderId, $reason)';
}

// Контекст задания: анализ граничных входов.

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

Вопрос 13 из 20

Какое утверждение корректно связывает показанный код с семантикой темы «Собственные исключения»?

final class InvalidOrder implements Exception {
  InvalidOrder(this.orderId, this.reason);
  final String orderId;
  final String reason;
  @override String toString() => 'InvalidOrder($orderId, $reason)';
}

// Контекст задания: проверка семантики фрагмента.

Собственное исключение должно описывать нарушение предметного контракта и хранить нужный контекст, а не заставлять вызывающий код разбирать текст сообщения. Порядок внутренних вызовов «Собственные исключения» считать публичной гарантией, которую нельзя менять при рефакторинге. Спорный результат «Собственные исключения» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. В теме «Собственные исключения» отсутствие предупреждения анализатора считать гарантией для любого допустимого входа. Случай «сохранение стека при преобразовании» объявить внутренней деталью «Собственные исключения», даже если клиент видит иной результат.

Вопрос 14 из 20

Две реализации решают задачу «Собственные исключения» по-разному. Какое требование делает их взаимозаменяемыми для клиента?

Для реализаций «Собственные исключения» требовать одинакового числа обращений к зависимостям при совпадающем результате. Перед вызовом «Собственные исключения» заставить клиента повторять валидацию, не описывая отказ самого компонента. В договоре «Собственные исключения» описать только успешный путь, оставив спорные входы на усмотрение реализации. Из «Собственные исключения» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте. Собственное исключение должно описывать нарушение предметного договора, а не просто переименовывать общий `Exception`.

Вопрос 15 из 20

Ручная проверка по теме «Собственные исключения» прошла. Как превратить её в полезную автоматическую регрессию?

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

Вопрос 16 из 20

Какое изменение показанного кода исправляет правило «Границы перехвата», а не маскирует один его симптом?

Future<Result> checkout() async {
  try {
    return await gateway.charge();
  } on TimeoutException catch (e, st) {
    throw PaymentUnavailable(cause: e, stackTrace: st);
  }
}

// Контекст задания: выбор места исправления.

Добавить в «Границы перехвата» специальный флаг только для одного экрана или сервиса, сохранив общий контракт. Скопировать защиту «Границы перехвата» во все найденные места вызова и считать повторение единым исправлением. В решении «Границы перехвата» перехватывать любое исключение и возвращать нейтральное значение без указания причины. Добавить обработку «слишком ранний перехват» в ближайший вызывающий метод, не меняя общий компонент «Границы перехвата». Перехватывать ошибку там, где можно восстановиться или добавить контекст, используя `rethrow` для сохранения стека.

Вопрос 17 из 20

Что здесь следует считать правилом «Границы перехвата», а что — лишь деталью текущей реализации?

Future<Result> checkout() async {
  try {
    return await gateway.charge();
  } on TimeoutException catch (e, st) {
    throw PaymentUnavailable(cause: e, stackTrace: st);
  }
}

// Контекст задания: проверка семантики фрагмента.

Спорный результат «Границы перехвата» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Различия между версиями SDK для «Границы перехвата» в этом выводе не учитываются. Случай «обработка на уровне без возможности восстановиться» объявить внутренней деталью «Границы перехвата», даже если клиент видит иной результат. Для «Границы перехвата» считать случаи «слишком ранний перехват, пустой `catch`, повторное выбрасывание без `rethrow`; обработка на уровне без возможности восстановиться» эквивалентными, если программа не завершается аварийно. Порядок внутренних вызовов «Границы перехвата» считать публичной гарантией, которую нельзя менять при рефакторинге. Вывод делают по поведению текущей реализации «Границы перехвата» на обычном входе. Перехватывать ошибку следует на уровне, который способен добавить контекст, восстановиться или преобразовать её; пустой широкий `catch` теряет причину и оставляет систему в неопределённом состоянии.

Вопрос 18 из 20

Код прошёл демонстрационный пример, но границы не разобраны. Что нужно проверить отдельно в теме «Границы перехвата»?

Future<Result> checkout() async {
  try {
    return await gateway.charge();
  } on TimeoutException catch (e, st) {
    throw PaymentUnavailable(cause: e, stackTrace: st);
  }
}

// Контекст задания: анализ граничных входов.

Составить отдельные сценарии для границ: слишком ранний перехват, пустой `catch`, повторное выбрасывание без `rethrow`; обработка на уровне без возможности восстановиться. Проверить для «Границы перехвата» только самый сложный случай «обработка на уровне без возможности восстановиться», считая остальные границы косвенно покрытыми. Во всех спорных входах «Границы перехвата» проверять только отсутствие необработанного исключения, не сравнивая состояние. Команда предполагает, что остальные входы «Границы перехвата» проходят по той же ветви. Автоматизировать обычный путь «Границы перехвата», а случай «обработка на уровне без возможности восстановиться» оставить в ручном чек-листе выпуска. Для «Границы перехвата» ограничиться случаем «слишком ранний перехват», а остальные входы считать тем же классом отказа. Так набор «Границы перехвата» выглядит компактнее и требует меньше поддержки.

Вопрос 19 из 20

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

Для границы «Границы перехвата» назначить то же ожидание, что и успеху, и проверять лишь отсутствие исключения. Сохранить сценарий «обработка на уровне без возможности восстановиться» в ручном чек-листе «Границы перехвата», не добавляя автоматическую проверку. Запускать проверку «Границы перехвата» после выпуска на рабочем трафике, а не до изменения зависимости. Для «Границы перехвата» оставить только тест обычного пути, а исправленный случай считать закрытым ревью. Проверить прохождение ошибки через несколько слоёв, сохранение трассировки и различие восстанавливаемого и фатального отказа.

Вопрос 20 из 20

Две реализации решают задачу «Границы перехвата» по-разному. Какое требование делает их взаимозаменяемыми для клиента?

Из «Границы перехвата» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте. Включить в договор «Границы перехвата» конкретный способ хранения состояния вместо наблюдаемого результата. Перед вызовом «Границы перехвата» заставить клиента повторять валидацию, не описывая отказ самого компонента. В договоре «Границы перехвата» описать только успешный путь, оставив спорные входы на усмотрение реализации. Каждый слой должен обрабатывать только те отказы, за которые он действительно отвечает.