Есть ли недостатки в autodie?

Ответ 1

Документация autodie содержит несколько ошибок и ошибок, о которых вам следует знать. Тем не менее, большинство из них относительно незначительны, а также фиксируются в конечном итоге.

Кроме того, нет реальных недостатков, кроме, может быть, дополнительной зависимости при работе на старых версиях perl. Тот факт, что он не используется очень часто, вполне может быть вызван тем, что он относительно новый. Тем не менее, autodie (и даже старый Fatal модуль), как правило, хорошая идея.

Ответ 2

Технология в основном прекрасна, но она действует на расстоянии и волшебна. Некоторые люди, которые читают только разделы кода, могут не понимать, что происходит с тех пор, как autodie находится далеко от кода, который они проверяют. Поскольку не все используют его, и это только стало практикой в ​​последнее время, я подозреваю, что большинство людей этого не ожидают. Это не очень важно, но мне кажется, что это всегда кажется уродливым.

Ответ 3

Существует языковая модель, которая соответствует парадигме, основанной на функциях C, где все функции возвращают значение, и пользователю нужно проверить возвращаемое значение. Perl находится в этой группе. Если я вызываю функцию, то я обязан проверить, действительно ли эта функция вернула что-то полезное.

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

Новые языки основаны на исключениях, потому что они обрабатывают ленивую проблему с разработчиками. В языках программирования стиля C, если разработчик забывает или не утруждает себя проверкой статуса выхода функции, программа продолжает работу. В языках программирования стиля Java программа умирает. В обоих случаях разработчик может справиться с проблемой недействительного результата функции, так что эти языки, основанные на исключениях, заставляют разработчиков делать это.

Почему вы не видите use autodie здесь? Несколько теорий:

Он новый

Прагма autodie довольно новая, и у большинства разработчиков нет хорошего способа включить новые знания в их программирование на Perl. Например, say существует с 5.10, но я все еще вижу, что немногие разработчики используют его, даже несмотря на то, что оно значительно улучшается по сравнению с print и прост в использовании. Если разработчик не узнает autodie, когда они изначально изучают Perl, они, вероятно, никогда не узнают об этом.

Нет синтаксиса Try/Catch в Perl

Здесь, как обычно работает 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 ( [email protected] ) {
   ...    # What I do if function "foo" doesn't return a good value...
}

Вы можете сказать yucky? Я знал, что ты сможешь! Поскольку $fh лексически ограничен, я должен объявить его перед моим eval. Кроме того, я даже не попал в проблему [email protected], являющуюся переменной с глобальным охватом!

Непосредственный путь

Большинство модулей и встроенных функций не работают с autodie, который более или менее ограничен IO-вызовами, 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 просто не делает много всего прямо сейчас.

Ответ 4

Еще одно соображение заключается в том, что autodie и utf8:: все не играли хорошо вместе до недавней версии utf8:: all. utf8:: all - еще один удобный модуль, который, как и autodie, помогает настроить Perl для выполнения общих задач (на этот раз unicode) автоматически.