💡 Инструкция: Выберите один ответ из пяти. Время — 55 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 4 тематических результатов и разбор всех ответов.
Вопрос 1 из 20
Не запуская пример, выберите точный итог для блока «Иерархия ошибок». Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Иерархия ошибок Копировать
# Проследите выполнение и выберите точный результат.
begin
10 / 0
rescue => error
p [error.class, 'handled']
end
p ZeroDivisionError < StandardError
ZeroDivisionError является StandardError, поэтому код выводит `handled`. Это объясняется тем, что bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException.
ZeroDivisionError является StandardError, поэтому код выводит `handled`. Это объясняется тем, что в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
Метод возвращает `:work`, но строка `cleanup` печатается перед выходом. Это объясняется тем, что bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException.
ZeroDivisionError является StandardError, поэтому код выводит `handled`. Это объясняется тем, что `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат. Это объясняется тем, что bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException.
Вопрос 2 из 20
Какая трассировка кода по теме «Обработка ошибок через rescue» не теряет важную деталь? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Ruby Ruby — Обработка ошибок через rescue Копировать
# Проследите выполнение и выберите точный результат.
require 'json'
result = begin
JSON.parse('{')
rescue JSON::ParserError
:bad_json
rescue StandardError
:other
end
p result
JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат. Причина такого результата: `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат. Причина такого результата: bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException.
JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат. Причина такого результата: в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
Код записывает класс ошибки, затем голый raise возвращает ту же ZeroDivisionError внешнему обработчику. Причина такого результата: в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
ZeroDivisionError является StandardError, поэтому код выводит `handled`. Причина такого результата: в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
Вопрос 3 из 20
Разберите выражения по порядку. Как завершится фрагмент из раздела «Гарантированное завершение через ensure»? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Ruby Ruby — Гарантированное завершение через ensure Копировать
# Проследите выполнение и выберите точный результат.
def run
:work
ensure
puts 'cleanup'
:ignored
end
p run
Метод возвращает `:work`, но строка `cleanup` печатается перед выходом. Такой итог следует из правила: в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
Метод возвращает `:work`, но строка `cleanup` печатается перед выходом. Такой итог следует из правила: в обработчике можно поднять текущее исключение снова через голый `raise`; новое исключение меняет класс, а исходную ошибку следует сохранить в цепочке `cause`.
JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат. Такой итог следует из правила: `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
Метод возвращает `:work`, но строка `cleanup` печатается перед выходом. Такой итог следует из правила: `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
ZeroDivisionError является StandardError, поэтому код выводит `handled`. Такой итог следует из правила: `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
Вопрос 4 из 20
Что покажет выполнение этого фрагмента из раздела «Повторная генерация»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Повторная генерация Копировать
# Проследите выполнение и выберите точный результат.
begin
begin
1 / 0
rescue => e
warn e.class.name
raise
end
rescue => outer
p outer.class
end
Код записывает класс ошибки, затем голый raise возвращает ту же ZeroDivisionError внешнему обработчику. Механизм результата таков: в обработчике можно поднять текущее исключение снова через голый `raise`; новое исключение меняет класс, а исходную ошибку следует сохранить в цепочке `cause`.
ZeroDivisionError является StandardError, поэтому код выводит `handled`. Механизм результата таков: в обработчике можно поднять текущее исключение снова через голый `raise`; новое исключение меняет класс, а исходную ошибку следует сохранить в цепочке `cause`.
Код записывает класс ошибки, затем голый raise возвращает ту же ZeroDivisionError внешнему обработчику. Механизм результата таков: `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
Код записывает класс ошибки, затем голый raise возвращает ту же ZeroDivisionError внешнему обработчику. Механизм результата таков: в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат. Механизм результата таков: в обработчике можно поднять текущее исключение снова через голый `raise`; новое исключение меняет класс, а исходную ошибку следует сохранить в цепочке `cause`.
Вопрос 5 из 20
Какое скрытое условие делает фрагмент «Иерархия ошибок» хрупким? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Иерархия ошибок Копировать
# Обычный запуск проходит. Найдите скрытый риск.
begin
10 / 0
rescue => error
p [error.class, 'handled']
end
p ZeroDivisionError < StandardError
Перехват Exception поглощает сигналы завершения и серьёзные системные ошибки, оставляя процесс в неопределённом состоянии. Причина — bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException.
Широкий StandardError в первой ветке делает последующие специальные обработчики недостижимыми и стирает различия причин. Причина — bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException.
Явный `return` внутри ensure подавляет исходное исключение или результат и делает расследование почти невозможным. Причина — bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException.
Перехват Exception поглощает сигналы завершения и серьёзные системные ошибки, оставляя процесс в неопределённом состоянии. Причина — в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
Перехват Exception поглощает сигналы завершения и серьёзные системные ошибки, оставляя процесс в неопределённом состоянии. Причина — `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
Вопрос 6 из 20
Какой рабочий сбой вероятнее всего связан именно с механизмом «Обработка ошибок через rescue»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Обработка ошибок через rescue Копировать
# Обычный запуск проходит. Найдите скрытый риск.
require 'json'
result = begin
JSON.parse('{')
rescue JSON::ParserError
:bad_json
rescue StandardError
:other
end
p result
Явный `return` внутри ensure подавляет исходное исключение или результат и делает расследование почти невозможным. Этот риск связан с тем, что в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
Широкий StandardError в первой ветке делает последующие специальные обработчики недостижимыми и стирает различия причин. Этот риск связан с тем, что `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
Перехват Exception поглощает сигналы завершения и серьёзные системные ошибки, оставляя процесс в неопределённом состоянии. Этот риск связан с тем, что в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
Широкий StandardError в первой ветке делает последующие специальные обработчики недостижимыми и стирает различия причин. Этот риск связан с тем, что bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException.
Широкий StandardError в первой ветке делает последующие специальные обработчики недостижимыми и стирает различия причин. Этот риск связан с тем, что в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
Вопрос 7 из 20
Почему успешный пример ещё не доказывает надёжность решения «Гарантированное завершение через ensure»? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Ruby Ruby — Гарантированное завершение через ensure Копировать
# Обычный запуск проходит. Найдите скрытый риск.
def run
:work
ensure
puts 'cleanup'
:ignored
end
p run
Явный `return` внутри ensure подавляет исходное исключение или результат и делает расследование почти невозможным. Уязвимое место возникает потому, что в одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких.
Перехват Exception поглощает сигналы завершения и серьёзные системные ошибки, оставляя процесс в неопределённом состоянии. Уязвимое место возникает потому, что `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
Явный `return` внутри ensure подавляет исходное исключение или результат и делает расследование почти невозможным. Уязвимое место возникает потому, что `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
Широкий StandardError в первой ветке делает последующие специальные обработчики недостижимыми и стирает различия причин. Уязвимое место возникает потому, что `ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return.
Явный `return` внутри ensure подавляет исходное исключение или результат и делает расследование почти невозможным. Уязвимое место возникает потому, что в обработчике можно поднять текущее исключение снова через голый `raise`; новое исключение меняет класс, а исходную ошибку следует сохранить в цепочке `cause`.
Вопрос 9 из 20
Какой контракт нужно помнить при ревью кода по теме «Иерархия ошибок»? Правильным считается только полностью согласованное утверждение.
Bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException. Поэтому метод возвращает `:work`, но строка `cleanup` печатается перед выходом.
В одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких. Поэтому zeroDivisionError является StandardError, поэтому код выводит `handled`.
Bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException. Поэтому zeroDivisionError является StandardError, поэтому код выводит `handled`.
Bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException. Поэтому JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат.
`ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return. Поэтому zeroDivisionError является StandardError, поэтому код выводит `handled`.
Вопрос 10 из 20
Какое правило Ruby или Rails объясняет поведение в теме «Обработка ошибок через rescue»? Нужен вариант без логического разрыва между первой и второй частью.
`ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return. Из этого следует, что JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат.
Bare `rescue` перехватывает StandardError и его потомков, но не системные исключения вроде NoMemoryError, SystemExit и SignalException. Из этого следует, что JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат.
В одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких. Из этого следует, что JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат.
В одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких. Из этого следует, что zeroDivisionError является StandardError, поэтому код выводит `handled`.
В одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких. Из этого следует, что код записывает класс ошибки, затем голый raise возвращает ту же ZeroDivisionError внешнему обработчику.
Вопрос 11 из 20
Какое свойство Ruby или Rails определяет результат примера «Гарантированное завершение через ensure»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
`ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return. Наблюдаемое следствие: JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат.
В обработчике можно поднять текущее исключение снова через голый `raise`; новое исключение меняет класс, а исходную ошибку следует сохранить в цепочке `cause`. Наблюдаемое следствие: метод возвращает `:work`, но строка `cleanup` печатается перед выходом.
`ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return. Наблюдаемое следствие: метод возвращает `:work`, но строка `cleanup` печатается перед выходом.
`ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return. Наблюдаемое следствие: zeroDivisionError является StandardError, поэтому код выводит `handled`.
В одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких. Наблюдаемое следствие: метод возвращает `:work`, но строка `cleanup` печатается перед выходом.
Вопрос 12 из 20
Как сформулировать правило блока «Повторная генерация» без лишних обещаний? В правильном ответе вторая часть действительно объясняет или проверяет первую.
В одном rescue можно перечислить классы ошибок; ветки проверяются сверху вниз, поэтому более узкие обработчики должны стоять раньше широких. Именно поэтому код записывает класс ошибки, затем голый raise возвращает ту же ZeroDivisionError внешнему обработчику.
В обработчике можно поднять текущее исключение снова через голый `raise`; новое исключение меняет класс, а исходную ошибку следует сохранить в цепочке `cause`. Именно поэтому код записывает класс ошибки, затем голый raise возвращает ту же ZeroDivisionError внешнему обработчику.
В обработчике можно поднять текущее исключение снова через голый `raise`; новое исключение меняет класс, а исходную ошибку следует сохранить в цепочке `cause`. Именно поэтому JSON::ParserError попадает в первую ветку и превращается в `:bad_json`, а не в общий результат.
`ensure` выполняется при обычном выходе, исключении и return; значение выражения ensure обычно не заменяет результат, если внутри нет явного return. Именно поэтому код записывает класс ошибки, затем голый raise возвращает ту же ZeroDivisionError внешнему обработчику.
В обработчике можно поднять текущее исключение снова через голый `raise`; новое исключение меняет класс, а исходную ошибку следует сохранить в цепочке `cause`. Именно поэтому zeroDivisionError является StandardError, поэтому код выводит `handled`.
Вопрос 14 из 20
Какое действие добавляет недостающую гарантию в блоке «Обработка ошибок через rescue»? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Обработка ошибок через rescue Копировать
# Выберите изменение, которое исправляет причину.
require 'json'
result = begin
JSON.parse('{')
rescue JSON::ParserError
:bad_json
rescue StandardError
:other
end
p result
Разделить ошибки, после которых можно продолжать, и ошибки, требующие отката или повторного выброса; не возвращать один nil для всех причин. Это изменение устраняет проблему: перехват Exception поглощает сигналы завершения и серьёзные системные ошибки, оставляя процесс в неопределённом состоянии.
После добавления контекста повторно поднимать исключение и сохранять cause; подавлять ошибку только при явно описанном восстановлении. Это изменение устраняет проблему: широкий StandardError в первой ветке делает последующие специальные обработчики недостижимыми и стирает различия причин.
Разделить ошибки, после которых можно продолжать, и ошибки, требующие отката или повторного выброса; не возвращать один nil для всех причин. Это изменение устраняет проблему: широкий StandardError в первой ветке делает последующие специальные обработчики недостижимыми и стирает различия причин.
Разделить ошибки, после которых можно продолжать, и ошибки, требующие отката или повторного выброса; не возвращать один nil для всех причин. Это изменение устраняет проблему: явный `return` внутри ensure подавляет исходное исключение или результат и делает расследование почти невозможным.
Использовать ensure только для освобождения ресурса и не возвращать из него значение; ошибки очистки связывать с исходной причиной. Это изменение устраняет проблему: широкий StandardError в первой ветке делает последующие специальные обработчики недостижимыми и стирает различия причин.
Вопрос 18 из 20
Что следует добавить в набор проверок по теме «Обработка ошибок через rescue», чтобы поймать редкий отказ? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Проверить ситуацию, где и основная операция, и очистка поднимают исключения: без осторожности исходная ошибка будет потеряна. Так проверяется решение: разделить ошибки, после которых можно продолжать, и ошибки, требующие отката или повторного выброса; не возвращать один nil для всех причин.
Проверить backtrace и cause после обёртки в собственный класс: они должны указывать на исходную операцию. Так проверяется решение: разделить ошибки, после которых можно продолжать, и ошибки, требующие отката или повторного выброса; не возвращать один nil для всех причин.
Проверить исключение, возникшее внутри самого rescue: оно не будет обработано соседней веткой этого же begin. Так проверяется решение: после добавления контекста повторно поднимать исключение и сохранять cause; подавлять ошибку только при явно описанном восстановлении.
Проверить исключение, возникшее внутри самого rescue: оно не будет обработано соседней веткой этого же begin. Так проверяется решение: разделить ошибки, после которых можно продолжать, и ошибки, требующие отката или повторного выброса; не возвращать один nil для всех причин.
Проверить исключение, возникшее внутри самого rescue: оно не будет обработано соседней веткой этого же begin. Так проверяется решение: использовать ensure только для освобождения ресурса и не возвращать из него значение; ошибки очистки связывать с исходной причиной.
Вопрос 19 из 20
Что следует добавить в набор проверок по теме «Гарантированное завершение через ensure», чтобы поймать редкий отказ? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Проверить backtrace и cause после обёртки в собственный класс: они должны указывать на исходную операцию. Проверка относится к изменению: использовать ensure только для освобождения ресурса и не возвращать из него значение; ошибки очистки связывать с исходной причиной.
Проверить исключение, возникшее внутри самого rescue: оно не будет обработано соседней веткой этого же begin. Проверка относится к изменению: использовать ensure только для освобождения ресурса и не возвращать из него значение; ошибки очистки связывать с исходной причиной.
Проверить ситуацию, где и основная операция, и очистка поднимают исключения: без осторожности исходная ошибка будет потеряна. Проверка относится к изменению: разделить ошибки, после которых можно продолжать, и ошибки, требующие отката или повторного выброса; не возвращать один nil для всех причин.
Проверить ситуацию, где и основная операция, и очистка поднимают исключения: без осторожности исходная ошибка будет потеряна. Проверка относится к изменению: использовать ensure только для освобождения ресурса и не возвращать из него значение; ошибки очистки связывать с исходной причиной.
Проверить ситуацию, где и основная операция, и очистка поднимают исключения: без осторожности исходная ошибка будет потеряна. Проверка относится к изменению: после добавления контекста повторно поднимать исключение и сохранять cause; подавлять ошибку только при явно описанном восстановлении.