Perl模块是否会引发异常(die / croak)?

在编写Perl模块时,在模块中使用croak / die是个好习惯吗?

毕竟,如果调用者不使用eval块,模块可能会使调用它的程序崩溃.

在这些情况下最好的做法是什么?

解决方法

我通常喜欢异常,如果你指出某种错误.否则,您不得不花费更多的时间在代码库的不同级别上花费错误处理代码,而不是将错误处理集中在系统的相应层中 – 其他原因.

你可能会发现这个old thread on 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);

>清晰度使用异常代码,“正常”控件流程更为明确,因为它不会被错误处理代码所掩盖.我认为上面的两个代码示例中的第一个比第二个代码更直接地显示代码的意图.
分离问题错误条件和错误处理程序是不同的想法.

>您可能希望根据上下文以不同的方式处理错误.
>您可能还不知道错误发生时应该如何处理.
>您可能不知道在编写代码时如何处理错误.

使用返回错误代码样式,您最终必须:

可以做出关于如何处理决定的错误条件.
>传播错误处理程序到可能发生错误的地方

如果在错误条件和错误处理程序之间存在很多级别的代码,那么这两个选项都将变得凌乱.
>返回值和错误条件之间不要混淆.

可能还有一些;-)

相关文章

1. 如何去重 #!/usr/bin/perl use strict; my %hash; while(...
最近写了一个perl脚本,实现的功能是将表格中其中两列的数据...
表的数据字典格式如下:如果手动写MySQL建表语句,确认麻烦,...
巡检类工作经常会出具日报,最近在原有日报的基础上又新增了...
在实际生产环境中,常常需要从后台日志中截取报文,报文的形...
最近写的一个perl程序,通过关键词匹配统计其出现的频率,让...