perl - 为什么我应该在 Perl 中使用 Carp 而不是警告？

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

这个小程序有点傻，但是当你想知道是谁调用了这个正在吹毛求疵的方法时，它会派上用场。

Answer 2

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

Damian 建议Carp不要在Perl Best Practiceswarn中的“报告失败”中推荐，但没有区分作为顶级代码结构的脚本和作为程序使用的组件的模块。

我最近几乎不关心这个，因为我一直在使用Log::Log4perl来处理所有这些。

Answer 3

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

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

Answer 4

Carp从调用者的角度报告错误。这对于您通常想要警告错误使用（例如缺少参数）并识别错误发生的位置而不是检测到的位置的模块很有用。这对于可能在许多地方使用的实用功能尤其重要。

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