SW Swift · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Обработка ошибок

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

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. В тесте 20 вопросов, на работу отведено 55 минут. В каждом задании верен только один вариант. Часть фрагментов намеренно содержит ошибку: определяйте её по коду, а не по внешнему виду ответа. После завершения откроются общий результат, 4 тематические шкалы и подробные объяснения.

Вопрос 1 из 20

Не запуская код, восстановите состояние значений после последней строки. Какой вывод верен для «Функции с throws»? Здесь оценивается распространение ошибки и выбор способа обработки.

enum ParseError: Error { case invalid }
func parse(_ text: String) throws -> Int {
    guard let value = Int(text) else { throw ParseError.invalid }
    return value
}
print(try parse("12"))

Вход корректен, функция не возвращает 12; try обязателен даже если конкретный вызов не выбрасывает ошибку. Наблюдаемый результат определяется тем, что `rethrows` разрешает функции бросать собственные ошибки без бросающего замыкания. Вход корректен, функция возвращает 13; try обязателен даже если конкретный вызов не выбрасывает ошибку. Операция с `ParseError` корректна, поскольку `defer` выполняется только при успешном выходе из функции. Вход корректен, функция возвращает 12; try обязателен даже если конкретный вызов не выбрасывает ошибку.

Вопрос 2 из 20

Где окажется состояние программы после выполнения всех показанных операций? Важно учесть: сопоставление ошибок и полнота обработки.

enum E: Error { case network, decode }
func run() throws { throw E.decode }
do {
    try run()
} catch E.network {
    print("network")
} catch {
    print("other")
}

Первая ветвь совпадает, общий catch перехватывает E.decode и печатает «other». Последняя строка ведёт себя именно так, потому что пустой `catch` сохраняет полный контракт отказа для вызывающей стороны. Первая ветвь не совпадает, общий catch не перехватывает E.decode и печатает «other». Первая ветвь не совпадает, общий catch перехватывает E.decode и печатает «other». Для этого примера достаточно учесть, что `try?` передаёт исходную ошибку в ближайший `catch`.

Вопрос 3 из 20

Какой из пяти выводов подтверждается построчной трассировкой? Не упускайте из виду следующее: преобразование success и сохранение failure.

let result: Result<Int, Error> = .success(4)
let doubled = result.map { $0 * 2 }
print(try doubled.get())

map преобразует только success, get возвращает 8 и не выбрасывает ошибку в этом случае. Фрагмент не требует отдельного условия: `rethrows` разрешает функции бросать собственные ошибки без бросающего замыкания. map преобразует только success, get возвращает 9 и не выбрасывает ошибку в этом случае. map преобразует только success, get не возвращает 8 и не выбрасывает ошибку в этом случае. flatMap преобразует только success, get возвращает 8 и не выбрасывает ошибку в этом случае.

Вопрос 4 из 20

Где окажется состояние программы после выполнения всех показанных операций? Важно учесть: обратный порядок и момент вычисления возвращаемого значения.

func demo() {
    defer { print("first") }
    defer { print("second") }
    print("body")
}
demo()

Фрагмент не требует отдельного условия: пустой `catch` сохраняет полный контракт отказа для вызывающей стороны. Операция с `demo` корректна, поскольку `rethrows` разрешает функции бросать собственные ошибки без бросающего замыкания. Сначала печатается body, затем catch выполняются в обратном порядке: second и first. Сначала печатается body, затем defer выполняются в обратном порядке: second и first. Наблюдаемый результат определяется тем, что `Result` скрывает тип ошибки и всегда эквивалентен Optional.

Вопрос 5 из 20

Что именно делает этот фрагмент неверным или неочевидным с точки зрения «Функции с throws»? Здесь оценивается распространение ошибки и выбор способа обработки.

func load() throws -> Int { 1 }
func wrapper() -> Int {
    try load()
}

Код не компилируется: функция-обёртка не обрабатывает ошибку и сама не объявлена throws. Причина сбоя в том, что пустой `catch` сохраняет полный контракт отказа для вызывающей стороны. Код компилируется: функция-обёртка не обрабатывает ошибку и сама не объявлена throws. Код не компилируется: функция-обёртка не обрабатывает ошибку и сама не объявлена rethrows. Код проходит проверку типов: функция-обёртка не обрабатывает ошибку и сама не объявлена throws.

Вопрос 6 из 20

Что именно делает этот фрагмент неверным или неочевидным с точки зрения «Обработка через do-catch»? Не упускайте из виду следующее: сопоставление ошибок и полнота обработки.

enum E2: Error { case a, b }
func f() throws { throw E2.b }

func testCatch() {
    do {
        try f()
    } catch E2.a {
        print("a")
    }
}

Причина сбоя в том, что `try?` передаёт исходную ошибку в ближайший `catch`. Фрагмент не компилируется без исчерпывающей обработки: do-catch здесь не ловит все возможные ошибки и не находится в rethrows-контексте. Фрагмент компилируется без исчерпывающей обработки: do-catch здесь не ловит все возможные ошибки и не находится в throws-контексте. Фрагмент не компилируется без исчерпывающей обработки: do-catch здесь не ловит все возможные ошибки и не находится в throws-контексте. Первой нарушенной гарантией здесь является предположение, что `defer` выполняется только при успешном выходе из функции.

Вопрос 7 из 20

Что именно делает этот фрагмент неверным или неочевидным с точки зрения «Тип Result»? Сосредоточьтесь на следующем: преобразование success и сохранение failure.

enum E3: Error { case bad }
let value: Result<Int, E3> = .failure(.bad)
let next = value.map { String($0) }
print(next)

map сохраняет failure с тем же типом ошибки; next имеет тип Optional<String, E3>. map сохраняет failure с тем же типом ошибки; next имеет тип Result<String, E3>. flatMap сохраняет failure с тем же типом ошибки; next имеет тип Result<String, E3>. Отчёт об ошибке должен указывать, что `defer` выполняется только при успешном выходе из функции. map не сохраняет failure с тем же типом ошибки; next имеет тип Result<String, E3>.

Вопрос 8 из 20

Какой диагноз согласуется и с исходным кодом, и с правилами Swift? Сосредоточьтесь на следующем: обратный порядок и момент вычисления возвращаемого значения.

func value(_ ok: Bool) -> Int {
    var x = 1
    defer { x += 10 }
    if ok { return x }
    return x * 2
}
print(value(true), value(false))

Отчёт об ошибке должен указывать, что `try?` передаёт исходную ошибку в ближайший `catch`. Возвращаемые выражения вычисляются до defer, поэтому печатается «1 3»; поздняя мутация x не меняет уже вычисленный результат. Возвращаемые выражения вычисляются до defer, поэтому печатается «1 2»; поздняя мутация x не меняет уже вычисленный результат. Возвращаемые выражения вычисляются до catch, поэтому печатается «1 2»; поздняя мутация x не меняет уже вычисленный результат. Возвращаемые выражения вычисляются до defer, поэтому печатается «2 2»; поздняя мутация x не меняет уже вычисленный результат.

Вопрос 9 из 20

Какой вариант ремонта вы бы приняли после содержательной проверки кода? Важно учесть: распространение ошибки и выбор способа обработки.

func load() throws -> Int { 1 }
func wrapper() -> Int {
    try load()
}

Либо добавить throws к функции-обёртке, либо обработать ошибку do-catch; try? уместен только при сознательной потере причины. Правка сводится к локальному обходу: пустой `catch` сохраняет полный контракт отказа для вызывающей стороны. Либо добавить throws к функции-обёртке, либо обработать ошибку do-catch; try! уместен только при сознательной потере причины. Либо добавить rethrows к функции-обёртке, либо обработать ошибку do-catch; try? уместен только при сознательной потере причины. Достаточно изменить работу с `load`, исходя из того, что `Result` скрывает тип ошибки и всегда эквивалентен Optional.

Вопрос 10 из 20

Выберите правку, после которой дефект исчезает не только в удачном примере. Проверяется сопоставление ошибок и полнота обработки.

enum E2: Error { case a, b }
func f() throws { throw E2.b }

func testCatch() {
    do {
        try f()
    } catch E2.a {
        print("a")
    }
}

Нужно адаптировать только вызов `E2`, поскольку пустой `catch` сохраняет полный контракт отказа для вызывающей стороны. Исправление — оставить контракт прежним и учитывать, что `try?` передаёт исходную ошибку в ближайший `catch`. Добавить общий catch, обработать остальные случаи или вынести вызов в функцию, которая сама объявлена throws. Достаточно изменить работу с `E2`, исходя из того, что `defer` выполняется только при успешном выходе из функции. Добавить общий catch, обработать остальные случаи или вынести вызов в функцию, которая сама объявлена rethrows.

Вопрос 11 из 20

Как восстановить заявленный контракт с наименьшим числом новых скрытых предположений? Сосредоточьтесь на следующем: преобразование success и сохранение failure.

enum E3: Error { case bad }
let value: Result<Int, E3> = .failure(.bad)
let next = value.map { String($0) }
print(next)

Достаточно изменить работу с `E3`, исходя из того, что `rethrows` разрешает функции бросать собственные ошибки без бросающего замыкания. Использовать mapError для преобразования ошибки, flatMap — когда преобразование само возвращает Result. Использовать mapError для преобразования ошибки, map — когда преобразование само возвращает Result. Использовать mapError для преобразования ошибки, flatMap — когда преобразование само не возвращает Result. Использовать mapError для преобразования ошибки, flatMap — когда преобразование само возвращает Optional.

Вопрос 12 из 20

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

func value(_ ok: Bool) -> Int {
    var x = 1
    defer { x += 10 }
    if ok { return x }
    return x * 2
}
print(value(true), value(false))

Использовать defer для симметричного освобождения ресурса рядом с его захватом, а не для скрытого изменения бизнес-результата. Использовать defer для симметричного освобождения ресурса рядом с его захватом, а для скрытого изменения бизнес-результата. Нужно адаптировать только вызов `value`, поскольку `defer` выполняется только при успешном выходе из функции. Сигнатуру можно не менять, если считать, что `try?` передаёт исходную ошибку в ближайший `catch`. Использовать catch для симметричного освобождения ресурса рядом с его захватом, а не для скрытого изменения бизнес-результата.

Вопрос 13 из 20

Что нужно учесть, прежде чем объявлять найденное правило универсальным? Важно учесть: распространение ошибки и выбор способа обработки.

Обычный `throws` фиксирует в сигнатуре один конкретный тип ошибки, поэтому остальные случаи компилятор исключает. `rethrows` сужает набор ошибок до первого типа, встретившегося в переданном замыкании. throws не определяет конкретный тип ошибки в сигнатуре обычной функции, поэтому вызывающий код должен быть готов к любому Error. `try?` сохраняет исходный `Error` внутри Optional, и его можно получить после проверки на `nil`. Вызывающему коду достаточно обработать одну наиболее вероятную ошибку: остальные автоматически превращаются в `nil`.

Вопрос 14 из 20

На какой границе входов, владения или времени жизни результат может стать другим? Здесь оценивается сопоставление ошибок и полнота обработки.

Контрпример появляется, когда `try?` передаёт исходную ошибку в ближайший `catch`. Граница применимости проходит там, где `defer` выполняется только при успешном выходе из функции. Порядок catch важен: более общий шаблон позже специфичного сделает последующий catch недостижимым. Пограничный случай связан с тем, что `rethrows` разрешает функции бросать собственные ошибки без бросающего замыкания. Порядок catch важен: более общий шаблон раньше специфичного сделает последующий catch недостижимым.

Вопрос 15 из 20

Какое ограничение темы «Тип Result» обязательно проверить отдельным граничным тестом? Сосредоточьтесь на следующем: преобразование success и сохранение failure.

Result удобно хранить и передавать как значение; throws throws обычно проще для линейного асинхронного кода. Result удобно хранить и передавать как значение; async throws обычно проще для линейного аасинхронного кода. Optional удобно хранить и передавать как значение; async throws обычно проще для линейного асинхронного кода. Ограничение определяется предположением, что `defer` выполняется только при успешном выходе из функции. Result удобно хранить и передавать как значение; async throws обычно проще для линейного асинхронного кода.

Вопрос 16 из 20

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

Контрпример появляется, когда `Result` скрывает тип ошибки и всегда эквивалентен Optional. defer не выполняется при выходе из текущей области, включая return и throw, но не спасает от принудительного завершения процесса. defer выполняется при выходе из текущей области, включая return и throw, но спасает от принудительного завершения процесса. catch выполняется при выходе из текущей области, включая return и throw, но не спасает от принудительного завершения процесса. defer выполняется при выходе из текущей области, включая return и throw, но не спасает от принудительного завершения процесса.

Вопрос 17 из 20

Как организовать этот механизм, чтобы владение и отказ оставались понятными после расширения проекта? Важно учесть: распространение ошибки и выбор способа обработки.

Для устойчивого решения достаточно принять, что `Result` скрывает тип ошибки и всегда эквивалентен Optional. В API и тестах следует исходить из правила: пустой `catch` сохраняет полный контракт отказа для вызывающей стороны. Главным проектным принципом здесь является утверждение, что `try?` передаёт исходную ошибку в ближайший `catch`. Ошибки подходят для ожидаемых отказов операции; нарушение внутреннего инварианта следует маскировать как рядовую ошибку ввода. Ошибки подходят для ожидаемых отказов операции; нарушение внутреннего инварианта не следует маскировать как рядовую ошибку ввода.

Вопрос 18 из 20

Какой подход делает неправильное использование заметным раньше? Здесь оценивается сопоставление ошибок и полнота обработки.

В обработчике нужно сохранять контекст исходной ошибки; превращение всех сбоев в одно сообщение лишает диагностику причинной цепочки. Архитектуру стоит строить из предположения, что `defer` выполняется только при успешном выходе из функции. Для устойчивого решения достаточно принять, что `rethrows` разрешает функции бросать собственные ошибки без бросающего замыкания. В API и тестах следует исходить из правила: `Result` скрывает тип ошибки и всегда эквивалентен Optional. Главным проектным принципом здесь является утверждение, что пустой `catch` сохраняет полный контракт отказа для вызывающей стороны.

Вопрос 19 из 20

Какой принцип важнее локальной красоты синтаксиса в рабочем приложении? Проверяется преобразование success и сохранение failure.

следует дублировать одну и ту же ошибку одновременно в Result, Optional и отдельном флаге: состояние становится несогласованным. Не следует дублировать одну и ту же ошибку одновременно в Result, Optional и отдельном флаге: состояние становится несогласованным. Не следует дублировать одну и ту же ошибку одновременно в Optional, Optional и отдельном флаге: состояние становится несогласованным. Не следует дублировать одну и ту же ошибку одновременно в Result, Result и отдельном флаге: состояние становится несогласованным. В API и тестах следует исходить из правила: `rethrows` разрешает функции бросать собственные ошибки без бросающего замыкания.

Вопрос 20 из 20

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

Несколько defer удобны для локальной очистки, однако сложная логика в них затрудняет чтение фактического порядка действий. При расширении системы нужно опираться на то, что `Result` скрывает тип ошибки и всегда эквивалентен Optional. Несколько defer удобны для глобальной очистки, однако сложная логика в них затрудняет чтение фактического порядка действий. Несколько catch удобны для локальной очистки, однако сложная логика в них затрудняет чтение фактического порядка действий. Главным проектным принципом здесь является утверждение, что `rethrows` разрешает функции бросать собственные ошибки без бросающего замыкания.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу