Существует языковая модель, которая следует C парадигме на основе функций, в которой все функции возвращают значение, и пользователь должен проверить возвращаемое значение.Perl в этой группе.Если я вызываю функцию, то я обязан проверить, действительно ли эта функция возвратила что-то полезное.
Существует другая языковая модель, которая следует парадигме на основе исключений в Java, где отказывающие функциивозвращать исключения, и если пользователь должен обработать исключение, он должен явно обработать исключение.Большинство современных языков, написанных с Java, следуют этому подходу на основе исключений .
Более новые языки основаны на исключениях , потому что он обрабатывает проблему lazy developer ,В языках программирования стиля C , если разработчик забывает или не пытается проверить состояние завершения функции, программа продолжается.На языках программирования Java программа умирает.В обоих случаях разработчик может справиться с проблемой неверного результата функции, так как языки на основе исключений заставляют разработчиков делать это.
Почему бы вам не увидеть use autodie здесь?Несколько теорий:
Это ново
Прагма autodie довольно нова, и у большинства разработчиков нет хорошего способа включить новые знания в свои программы на Perl.Например, say существует с 5.10, но я все еще вижу, что немногие разработчики используют его, хотя это большое улучшение по сравнению с print и простое в использовании.Если разработчик не изучает autodie, когда он первоначально изучает Perl, он, вероятно, никогда не узнает об этом.
В Perl нет синтаксиса Try / Catch
Вот как обычно работает Perlработает:
open $fh, "<", $file;
if ( not defined $fh ) {
... # What I do if `$fh` didn't get set.
}
Я проверяю значение $fh после моего оператора open (Хорошо, обычно вы проверяете возвращаемое значение open, а не открытое $fh, но терпитемне!).Синтаксис довольно прост и понятен.Это легко понять.
Что если вы использовали autodie и выбрали подход, основанный на исключениях?В Perl нет встроенного оператора try/catch, как в Java.Вместо этого вы выбираете полуклюжий способ использования eval:
use autodie;
my $fh; # Got to be declared outside of the eval
eval {
open $fh, "<", $file;
}; # Don't forget that semicolon!
if ( $@ ) {
... # What I do if function "foo" doesn't return a good value...
}
Можете ли вы сказать, что он ненормальный?Я знал, что ты мог!Поскольку $fh имеет лексическую область, я должен объявить это до моего eval.Кроме того, я даже не вникну в проблему $@, являющуюся переменной глобальной области действия!
Это путь неполный
Большинство модулей и встроенных функций не работают с autodie который более или менее ограничен вызовами ввода-вывода fork, system и exec. Даже здесь он неполон: print и flock не работают с autodie.Кроме этого, никакая другая встроенная функция Perl не работает с autodie.Удаление значений из пустого массива не вынуждает мою программу ломиться.Немногие модули проверяют состояние autodie, чтобы увидеть, должны ли их функции или методы croak вместо возврата ложных значений.Таким образом, сама идея превращения Perl в язык, основанный на исключениях, не происходит.
Даже в тех местах, где вы думаете, autodie сработает, просто нет.Если вы используете File::Copy для получения команд copy и move, не полагайтесь на autodie для обнаружения неверной копии файла.Вам все еще нужно проверить возвращаемое значение copy.Если вы используете File::IO, все ставки с autodie отключены.
Так что autodie не вполне соответствует его смелому обещанию превратить Perl в язык программирования, основанный на более исключительных ситуациях.Для большинства людей это в основном ловит операторы open, и у большинства разработчиков нет проблем с open ... or die....
Мне нравится подход к разработке на основе исключений, и я считаю, что по умолчанию все модули должны работать с ошибками.Заставьте разработчиков обрабатывать исключения, а не игнорировать их.Я пишу свои модули и функции для квака, когда возникают проблемы, и использую eval для обработки исключений.К сожалению, autodie сейчас ничего не делает.