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

Вопрос 1 из 25

Как точнее всего описать действие фрагмента с `$_` и `parse`?

sub parse { die "bad input
" unless $_[0] =~ /:/; return 1 }
eval { parse('x') };
say $@;

Die прерывает блок eval, а сообщение попадает в $@; перевод строки не даёт Perl дописать файл и строку. Поведение кода сводится к одной границе механизма: die с объектом сохраняет структурированную ошибку в $@, но вызывающий код должен уметь отличить объект от строки. Показанный участок сработает иначе: Строковый eval компилирует и выполняет данные как Perl-код, поэтому непроверенный ввод превращается в выполнение кода. В показанном коде «Ошибки выполнения» проявляется другой эффект: строковый eval компилирует и выполняет данные как Perl-код, поэтому непроверенный ввод превращается в выполнение кода. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: Блочный eval перехватывает ошибку выполнения без интерпретации строки как кода.

Вопрос 2 из 25

Какое описание не теряет важный побочный эффект участка с `risky`, `cleanup` и `log_error`?

eval { risky() };
cleanup();
if ($@) { log_error($@) }

Cleanup не может сам изменить $@, поэтому исходную ошибку нужно скопировать сразу после eval. Cleanup может сам изменить $@, поэтому исходную ошибку нужно скопировать сразу после eval. Cleanup может сам изменить $@, поэтому исходную ошибку не нужно скопировать сразу после eval. Cleanup может сам изменить $@, поэтому исходную успех нужно скопировать сразу после eval. Cleanup может сам изменить $@, поэтому исходную ошибку нужно скопировать только при следующем вызове после eval.

Вопрос 3 из 25

Какое описание не теряет важный побочный эффект участка с `$err`, `$_` и `risky`?

use Try::Tiny;
try { risky() } catch { my $err=$_; warn $err };

В показанном случае решающим становится только ограничение: finally выполняется и при успехе, и при ошибке, но не должен скрывать исходное исключение новой ошибкой очистки. Try::Tiny передаёт пойманную успех в $_ и избегает ряда ловушек прямой работы с $@. При выполнении первым проявится другое последствие: return внутри блоков Try::Tiny возвращает из анонимного блока, а не обязательно из окружающей подпрограммы; такой код легко понять неверно. Try::Tiny передаёт пойманную ошибку в $_ и избегает ряда ловушек прямой работы с $@. Исходная реализация уже содержит нужную защиту: Возврат из внешней функции записан явно после конструкции обработки.

Вопрос 4 из 25

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

eval { parse($row); store($row) };
if ($@) { warn 'skip' }

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

Вопрос 5 из 25

Не запуская фрагмент «Читаемость решения», выберите точное описание его работы.

eval { open my $fh,'<',$p or die "open: $!"; decode($fh) };

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

Вопрос 6 из 25

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

eval 'system($user_text)';

Основная проблема здесь — сам результат штатного случая: die прерывает блок eval, а сообщение попадает в $@; перевод строки не даёт Perl дописать файл и строку. Показанный код уже соблюдает правило «Для обработки исключений используют блочный eval; строковый eval нужен лишь для осознанной динамической компиляции доверенного кода», поэтому отдельного дефекта нет. Причину отказа точнее описывает соседняя граница темы: die с объектом сохраняет структурированную ошибку в $@, но вызывающий код должен уметь отличить объект от строки. Сбой создаёт именно предложенное исправление: Блочный eval перехватывает ошибку выполнения без интерпретации строки как кода. Строковый eval компилирует и выполняет данные как Perl-код, поэтому непроверенный ввод превращается в выполнение кода.

Вопрос 7 из 25

Что в этом коде нарушает ожидаемое поведение?

eval { risky() };
if ($@ =~ /timeout/) {
    retry_request();
}

Риск появляется после применения рекомендуемой правки: Признак успеха и копия ошибки фиксируются до дальнейших вызовов. Сопоставление по тексту хрупко: другая ошибка может содержать слово timeout, а формат сообщения измениться. Источником отказа служит нормальный итог выполнения: cleanup может сам изменить $@, поэтому исходную ошибку нужно скопировать сразу после eval. Дефект следует искать в другой оговорке: Пустой $@ не всегда доказывает успех строкового eval с ложным результатом; отдельный флаг 1 в конце блока устраняет неоднозначность. Сопоставление по тексту хрупко: другая ошибка не может содержать слово timeout, а формат сообщения измениться.

Вопрос 8 из 25

Какой отказ объясняется показанным кодом, а не внешней системой?

try { return compute() } catch { return fallback() };

Return внутри блоков Try::Tiny возвращает из анонимного блока, а не обязательно из окружающей подпрограммы; такой код легко понять неверно. Причина сбоя совпадает с обычным результатом примера: Try::Tiny передаёт пойманную ошибку в $_ и избегает ряда ловушек прямой работы с $@. Проблема возникает в исправленном варианте: Возврат из внешней функции записан явно после конструкции обработки. Существенная проблема здесь связана с иной границей: finally выполняется и при успехе, и при ошибке, но не должен скрывать исходное исключение новой ошибкой очистки. Return внутри блоков Try::Tiny не возвращает из анонимного блока, а не обязательно из окружающей подпрограммы; такой код легко понять неверно.

Вопрос 9 из 25

Где находится первопричина возможного сбоя в коде с `@rows` и `process_entire_batch`?

eval { process_entire_batch(@rows) };

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

Вопрос 10 из 25

Какую границу автор фрагмента «Читаемость решения» не учёл?

die 'Error';

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

Вопрос 11 из 25

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

my $ok = eval { parse($text); 1 };
if (!$ok) {
    my $error = $@;
    report_error($error);
}

После изменения сохраняется прежний дефект: Строковый eval компилирует и выполняет данные как Perl-код, поэтому непроверенный ввод превращается в выполнение кода. Правка лишь воспроизводит исходное поведение: die прерывает блок eval, а сообщение попадает в $@; перевод строки не даёт Perl дописать файл и строку. Блочный eval перехватывает успех выполнения без интерпретации строки как кода. Блочный eval перехватывает ошибку выполнения без интерпретации строки как кода. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: die с объектом сохраняет структурированную ошибку в $@, но вызывающий код должен уметь отличить объект от строки.

Вопрос 12 из 25

Как правка с `$ok`, `$err` и `risky` меняет поведение на неудобном входе?

my $ok = eval { risky(); 1 };
my $err = $@;
cleanup();
handle($err) unless $ok;

Правка лишь воспроизводит исходное поведение: cleanup может сам изменить $@, поэтому исходную ошибку нужно скопировать сразу после eval. Признак успеха и копия ошибки фиксируются до дальнейших вызовов. Признак ошибкуа и копия ошибки фиксируются до дальнейших вызовов. После изменения сохраняется прежний дефект: Сопоставление по тексту хрупко: другая ошибка может содержать слово timeout, а формат сообщения измениться. Признак успеха и ссылка ошибки фиксируются до дальнейших вызовов.

Вопрос 13 из 25

Что изменилось в работе фрагмента «Обработка ошибок с Try::Tiny»?

my $value;
try { $value=compute() } catch { $value=fallback($_) };
return $value;

Правка лишь воспроизводит исходное поведение: Try::Tiny передаёт пойманную ошибку в $_ и избегает ряда ловушек прямой работы с $@. Возврат из внешней функции записан неявно после конструкции обработки. Возврат из внешней функции записан явно после конструкции обработки. После изменения сохраняется прежний дефект: return внутри блоков Try::Tiny возвращает из анонимного блока, а не обязательно из окружающей подпрограммы; такой код легко понять неверно. Польза изменения состоит только в снятии такой оговорки: finally выполняется и при успехе, и при ошибке, но не должен скрывать исходное исключение новой ошибкой очистки.

Вопрос 14 из 25

Почему новая версия с `$row`, `@rows` и `$ok` устраняет исходный дефект?

for my $row (@rows) { my $ok=eval { my $v=parse($row); store($v); 1 }; handle_row_error($row,$@) unless $ok }

После изменения сохраняется прежний дефект: Слишком широкая граница откатывает или скрывает состояние множества записей при одной ошибке. Правка лишь воспроизводит исходное поведение: Блок перехватывает и ошибки парсинга, и ошибки записи, поэтому причина и безопасное продолжение становятся неразличимы. Граница совпадает с единицей восстановления — одной записью — и не сохраняет контекст ошибки. Граница совпадает с единицей восстановления — одной записью — и сохраняет контекст ошибки. Граница не совпадает с единицей восстановления — одной записью — и сохраняет контекст ошибки.

Вопрос 15 из 25

Как исправленный код с `%s`, `$p` и `$err` сохраняет исходное назначение?

die sprintf('decode %s: %s', safe_name($p), $err);

Гарантию исправления даёт исчезновение ограничения: Оборачивание ошибки должно сохранять исходную причину; полная замена текста одинаковым «что-то пошло не так» уничтожает цепочку. Ошибка содержит действие и безопасный контекст, не раскрывая секретный полный путь или содержимое. Изменение формы записи само по себе обеспечивает правило «Хорошая ошибка сообщает, что не удалось, над каким объектом и по какой причине, но не публикует секреты». Правка лишь воспроизводит исходное поведение: Сообщение добавляет операцию и системную причину, но для диагностики полезно также включить безопасный идентификатор файла. После изменения сохраняется прежний дефект: Общее сообщение теряет операцию, вход и первопричину, поэтому расследовать сбой почти невозможно.

Вопрос 16 из 25

Какое правило отделяет семантику Perl от случайно удачного запуска?

Общее правило темы «Ошибки выполнения» сводится к частному результату: die прерывает блок eval, а сообщение попадает в $@; перевод строки не даёт Perl дописать файл и строку. Весь контракт блока обеспечивает такая правка: Блочный eval перехватывает ошибку выполнения без интерпретации строки как кода. Правило «Для обработки исключений используют блочный eval; строковый eval нужен лишь для осознанной динамической компиляции доверенного кода» гарантирует, что ограничение «die с объектом сохраняет структурированную ошибку в $@, но вызывающий код должен уметь отличить объект от строки» больше не проявится. Для обработки исключений используют блочный eval; строковый eval нужен лишь для осознанной динамической компиляции доверенного кода. Основной принцип блока описывает только такой риск: Строковый eval компилирует и выполняет данные как Perl-код, поэтому непроверенный ввод превращается в выполнение кода.

Вопрос 17 из 25

Что является главным ориентиром при работе с «Состояние ошибки в переменной $@»?

Правило «$@ — глобальная специальная переменная с динамическим поведением, поэтому её читают и сохраняют немедленно» гарантирует, что ограничение «Пустой $@ не всегда доказывает успех строкового eval с ложным результатом; отдельный флаг 1 в конце блока устраняет неоднозначность» больше не проявится. Общее правило исчерпывается единственной правкой: Признак успеха и копия ошибки фиксируются до дальнейших вызовов. Главный ориентир — не допустить следующую ситуацию: Сопоставление по тексту хрупко: другая ошибка может содержать слово timeout, а формат сообщения измениться. Общее правило темы «Состояние ошибки в переменной $@» сводится к частному результату: cleanup может сам изменить $@, поэтому исходную ошибку нужно скопировать сразу после eval. $@ — глобальная специальная переменная с динамическим поведением, поэтому её читают и сохраняют немедленно.

Вопрос 18 из 25

Какой общий принцип темы «Обработка ошибок с Try::Tiny» переносится на другие программы?

Правило «Try::Tiny упрощает перехват, но не определяет иерархию ошибок, политику повторов и границы ответственности» гарантирует, что ограничение «finally выполняется и при успехе, и при ошибке, но не должен скрывать исходное исключение новой ошибкой очистки» больше не проявится. Общее правило темы «Обработка ошибок с Try::Tiny» сводится к частному результату: Try::Tiny передаёт пойманную ошибку в $_ и избегает ряда ловушек прямой работы с $@. Try::Tiny упрощает перехват, но не определяет иерархию ошибок, политику повторов и границы ответственности. Достаточно применить следующее исправление: Возврат из внешней функции записан явно после конструкции обработки. Для ревью достаточно исключить частный дефект: return внутри блоков Try::Tiny возвращает из анонимного блока, а не обязательно из окружающей подпрограммы; такой код легко понять неверно.

Вопрос 19 из 25

Какое положение темы «Границы обработки» помогает выбрать надёжную реализацию?

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

Вопрос 20 из 25

Какой общий принцип темы «Читаемость решения» переносится на другие программы?

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

Вопрос 21 из 25

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

Ограничение «die с объектом сохраняет структурированную ошибку в $@, но вызывающий код должен уметь отличить объект от строки» исчезает, если обычный пример один раз завершился успешно. Базовое правило «Для обработки исключений используют блочный eval; строковый eval нужен лишь для осознанной динамической компиляции доверенного кода» автоматически снимает указанную границу. Die с объектом не сохраняет структурированную ошибку в $@, но вызывающий код должен уметь отличить объект от строки. Die с объектом сохраняет структурированную ошибку в $@, но вызывающий код должен уметь отличить объект от строки. Die с объектом сохраняет структурированную ошибку в $@, но вызывающий код не должен уметь отличить объект от строки.

Вопрос 22 из 25

Какое ограничение блока «Состояние ошибки в переменной $@» следует проверять отдельным примером?

Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Пустой $@ не всегда доказывает успех строкового eval с ложным результатом; отдельный флаг 1 в конце блока устраняет неоднозначность. Достаточно включить strict и warnings, чтобы пограничный случай стал невозможен. Ограничение «Пустой $@ не всегда доказывает успех строкового eval с ложным результатом; отдельный флаг 1 в конце блока устраняет неоднозначность» исчезает, если обычный пример один раз завершился успешно. Базовое правило «$@ — глобальная специальная переменная с динамическим поведением, поэтому её читают и сохраняют немедленно» автоматически снимает указанную границу.

Вопрос 23 из 25

Какой предел гарантий блока «Обработка ошибок с Try::Tiny» остаётся в силе после успешного запуска?

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

Вопрос 24 из 25

Что важно отдельно проверить при переносе приёма «Границы обработки» в рабочий код?

Ограничение «Продолжать после ошибки безопасно лишь когда частичное состояние известно и изолировано» исчезает, если обычный пример один раз завершился успешно. Режимы strict и warnings полностью снимают это ограничение. Продолжать после ошибки безопасно лишь когда частичное состояние известно и изолировано. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Базовое правило «Исключение перехватывают там, где можно добавить контекст, восстановиться или преобразовать его; без такой возможности лучше дать ему подняться выше» автоматически снимает указанную границу.

Вопрос 25 из 25

Какое различие в механизме «Читаемость решения» чаще всего теряют при обобщении?

Ограничение «Оборачивание ошибки должно сохранять исходную причину; полная замена текста одинаковым «что-то пошло не так» уничтожает цепочку» исчезает, если обычный пример один раз завершился успешно. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Базовое правило «Хорошая ошибка сообщает, что не удалось, над каким объектом и по какой причине, но не публикует секреты» автоматически снимает указанную границу. Оборачивание ошибки должно сохранять исходную причину; полная замена текста одинаковым «что-то пошло не так» уничтожает цепочку. Режимы strict и warnings полностью снимают это ограничение.