为什么我应该在Perl中使用Carp而不是warn

Question

人们不断给我举鲤鱼的例子，而不是警告。为什么？是什么让鲤鱼比警告更好？

Answer 1

carp为您提供了有关消息来源（上下文）的更多信息

#!/usr/bin/perl
use Carp;
foo();
bar();
baz();
sub foo {
  warn "foo";
}
sub bar {
  carp "bar";
}
sub baz {
  foo();
  bar(); 
}

产生

foo at ./foo.pl line 9.
bar at ./foo.pl line 13
        main::bar() called at ./foo.pl line 6
foo at ./foo.pl line 10.
bar at ./foo.pl line 14
        main::bar() called at ./foo.pl line 19
        main::baz() called at ./foo.pl line 7

这个小程序有点傻，但当你想知道是谁调用了carp'ing方法时，它就派上了用场。

Answer 2

我将warn用于脚本和简单程序，并在任何模块中使用Carp。Carp子例程使用调用当前子例程的文件名和行号，因此更容易找到问题的原因（而不仅仅是问题本身的位置）。

Damian在Perl最佳实践的"报告失败"中建议使用Carp而不是warn，但没有区分作为顶级代码结构的脚本和作为程序使用的组件的模块。

我最近基本上不在乎这些，因为我一直在使用Log:：Log4perl来处理所有这些。

Answer 3

鲤鱼更适合在模块内进行调试。如果你只是写一个简单的脚本，那就没有任何好处。来自鲤鱼文档：

Carp例程在您自己的模块中很有用，因为它们的行为类似于die（）或warn（），但带有一条对模块用户更有用的消息。在cluck、concury和longmess的情况下，上下文是调用堆栈中每个调用的摘要。对于较短的消息，您可以使用鲤鱼或沙鱼，它们报告错误来自调用模块的位置。不能保证这就是错误所在，但这是一个很好的猜测。

Answer 4

Carp从调用者的角度报告错误。这对于您通常希望警告错误使用（例如，缺少参数）并确定错误发生的位置而不是检测到错误的位置的模块非常有用这对于可能在许多地方使用的实用程序函数来说尤其重要。

大多数作者在脚本中使用warn，在模块中使用carp。有时，当我希望错误消息反映模块实现中的问题时（例如，它应该支持但不支持的情况），我会在模块内部使用warn。有争议的是，cluck在这种情况下会更好，因为它提供了完整的堆栈回溯。