Каковы лучшие практики для обработки ошибок в Perl?
Я изучаю Perl, и в большом количестве примеров я вижу, что ошибки обрабатываются как это
open FILE, "file.txt" or die $!;
die посреди сценария действительно лучший способ иметь дело с ошибкой?
5 ответов
Подходит ли die в середине сценария, действительно зависит от того, что вы делаете. Если это всего лишь десятки строк, то ничего страшного. Небольшой инструмент с парой сотен строк, затем подумайте о признании (см. Ниже). Если это большая объектно-ориентированная система с множеством классов и взаимосвязанным кодом, то, возможно, объект исключения будет лучше.
признаются в пакете Carp :
Часто ошибка, которая привела к кубику, не упоминается в строке, о которой сообщает кубик.
Замена die на confess (см. Пакет Carp) даст трассировку стека (как мы добрались до этой строки), которая очень помогает при отладке.
Для обработки исключений из встроенных команд Perl я предпочитаю использовать autodie . Он перехватывает сбои из open и других системных вызовов и генерирует исключения для вас без необходимости выполнять бит или die . Эти исключения могут быть обнаружены с помощью eval {} или, что еще лучше, с помощью Try :: Tiny .
Если у вас нет более конкретной идеи, то да вы хотите умереть, когда происходят неожиданные вещи.
Умереть при невозможности открыть файл и указать его имя лучше, чем если система скажет вам, что не может читать из анонимного неопределенного файла или писать в него.
Если вы говорите о "скрипте", в общем случае вы говорите о довольно простом куске кода. Не слои, которые нуждаются в координации (не обычно). В Perl Module есть сопутствующая идея, что вы не владеете средой выполнения, так что либо основное программное обеспечение заботится, и оно ловит вещи в eval, ИЛИ оно не очень заботится, и умирание будет в порядке вещей. Однако, стоит попробовать немного повысить надежность модуля и просто передавать обратно undefs или что-то в этом роде.
Вы можете поймать все, что умирает (или умирает) в блоке eval. И вы можете сделать более специфическую обработку там.
Но если вы хотите проверить $!, то напишите этот код, и у вас будет более конкретное разрешение.
Посмотрите на почти универсальный стандарт использования
strict. Это код, который умирает на сомнительном синтаксисе, вместо того, чтобы позволить вам продолжить работу.
Итак, я думаю, общая идея такова: да, DIE если у вас нет лучшего представления о том, как все должно быть обработано. Если вы достаточно предусмотрительны, вам могут простить один или два раза, когда вы не умираете, потому что вы знаете, что вам это не нужно.
Более современный подход заключается в использовании стандартной библиотеки Carp.
use Carp;
my $fh;
open $fh, '<', "file.txt" or confess($!);
Основное преимущество заключается в том, что она дает трассировку стека при смерти.
Я использую die, но оборачиваю его в блоки eval для контроля над обработкой ошибок:
my $status = eval
{
# Some code...
};
Если 'eval' не удался:
$statusбудет неопределен.$@будет установлен в любое сообщение об ошибке (или в содержимое файлаdie).die)
При успешном выполнении 'eval':
$statusбудет последним возвращаемым значением блока.$@будет установлен в ''.
Поскольку я использую Log :: Log4perl почти везде, я использую $ logger-> logdie вместо die . А если вы хотите иметь больший контроль над исключениями, рассмотрите Exception :: Class .
Лучше ловить исключения с помощью Try :: Tiny (см. Его документацию, почему).