Должен ли модуль Perl вызывать исключения (die / croak)?

Question

При написании модуля Perl рекомендуется ли использовать croak / die внутри модуля?

В конце концов, если вызывающая сторона не использует блок eval, модуль может вызвать сбой программы, вызывающейэто.

Какова лучшая практика в этих случаях?

Answer 1

Я обычно предпочитаю исключения, если вы указываете какую-то ошибку. В противном случае вам придется тратить гораздо больше времени на разбрасывание кода обработки ошибок на разных уровнях вашей кодовой базы, а не на централизацию обработки ошибок на соответствующих уровнях системы - среди прочих причин.

Вы можете найти эту старую ветку на perlmonks полезным чтением. Ниже я воспроизведу свой комментарий - поскольку я в основном согласен с тем, что я написал тогда: -)

---

Некоторые причины, по которым мне нравятся исключения:

• грубость. Я могу забыть проверить возвращаемое значение ошибки. Я не могу забыть проверить исключение.

• Краткость. Я предпочитаю:

  $o->foo->bar->fribble->ni
  

  до

  $o->foo or return(ERROR_FOO);
  $o->bar or return(ERROR_BAR);
  $o->fribble or return(ERROR_FRIBBLE);
  $o->ni or return(ERROR_NI);
  

• Clarity. За исключением кода, основанного на исключениях, «нормальный» поток управления является более явным, поскольку он не скрыт кодом обработки ошибок. Я думаю, что в первом из двух приведенных выше примеров кода цель кода более очевидна, чем во втором.

• Разделение интересов. Условие ошибки и обработчик ошибок - разные идеи.

  • Вы можете захотеть, чтобы ошибка обрабатывалась различными способами в зависимости от контекста.

  • Вы также можете не знать, как следует обрабатывать ошибку в том месте, где она возникла.

  • Вы можете не знать, как следует обрабатывать ошибку, во время написания кода.

  При использовании кода возврата кода ошибки вам в конечном итоге придется:

  • Распространение ошибок в тех случаях, когда может быть принято решение о том, как их следует обрабатывать.

  • Распространение обработчиков ошибок до места возникновения ошибок

  Обе опции быстро становятся беспорядочными, если между условием ошибки и обработчиком ошибки существует много уровней кода.

• Нет путаницы между возвращаемыми значениями и условиями ошибки.

Возможно, есть еще немного; -)

Answer 2

По крайней мере, на ранних стадиях производства, мне нравится иметь много бросков исключений (умереть рано девизом). Так что я могу быстро уловить любую ошибку (и сэкономить много времени, избегая размышлений в логике и отслеживания кодов возврата). Затем в каждой итерации выпуска я могу уменьшить серьезность бросков, связывая их с состоянием $ o-> debug. Поэтому, когда вы запускаете свои тесты, умираете во всем, но когда вы запускаете свой код для настоящего хруста, вместо этого в журнал и умираете только тогда, когда происходят неизбежные фатальные условия. По моему скромному мнению, это более гибко, чем коды возврата, которые я использовал в старые времена.

Также простое исключение 'die' иногда не очень полезно, поэтому лучше иметь функцию throw, которая печатает всю трассировку стека вызовов (например, Carp-> confess () | cluck ()).

И хороший механизм ловли также удобен. используйте Try :: Tiny или TryCatch .

PD: нить perlmonk, на которую указывает Адриан, - классика.