21

perlcritic抱怨以下代码,一些运行良好的样板 DBI 东西,应该croak代替die

# Connect to database
my $db_handle = DBI->connect( $url, $user, $password ) or die $DBI::errstr;

所有这一切,而 die 似乎对我来说很好用。

我认为对于武士 Perl 战士来说,当事情出错时,呱呱叫声比实际死更不光彩。笑话分开

我为什么要croak代替die

不听 Perlcritic 的建议会有什么后果?

4

6 回答 6

36

来自http://www.perlmonks.org/?node_id=685452

当错误是您或您的代码没有正确执行时,您使用 die。当您的呼叫者做得不对时,您会使用 croak。死“错误:$!” 指示错误在发生错误的行上。呱呱“错误:$!” 表示错误出现在调用者调用您的代码的那一行。

在这种情况下,错误(与 DB 的连接错误)与调用者无关,与建立连接的线路有关,所以我会使用die.

于 2010-11-11T16:07:49.533 回答
8

我通常使用以下内容:

  • die "string"对于要直接与用户交流的致命消息。我主要在脚本中执行此操作。
  • die $object对于完整的异常对象,尽管大多数异常类都会throw为您提供方法。这是为了当你的调用者应该能够判断你抛出了什么样的错误,甚至可能从中提取信息。如果您使用Moose,请查看ThrowableThrowable-X
  • croak "message"就像阿德里安所说的那样,当您的用户做错了事,并且您想在任何调用您的代码时报告错误。函数和 API 级别的方法是这种情况的常见情况。
  • confess "message"对于我还没有看到异常有用性的库错误。这些通常是您认为是错误的运行时错误,而不是异常情况。对这些使用异常是有意义的,特别是如果您有一个已经使用异常的大型项目。但这是获取错误堆栈跟踪的好方法。
于 2010-11-11T16:50:06.227 回答
3

使用它不一定是错误的,die()croak()可以为您或您的用户提供有关问题所在的更多信息。还可以在Carp命名空间中设置变量,这些变量可以更改此输出以获取更多或更少的信息。

它相当于die()但有更多的信息和控制。

于 2010-11-11T16:06:23.410 回答
3

如果我们在函数之外调用 die 和 croak,这些函数之间没有区别。

只有当我们在任何其他函数中调用 die 和 croak 时,我们才能发现差异。

croak 将提供有关调用者的信息,例如函数名称和行号..等。die 将给出错误并给出发生错误的行号。

于 2016-07-13T12:08:57.073 回答
0

仍然。如果连接参数直接来自其他人指出的函数的输入,则此示例可能要使用 croak。

如果您为自己编写一个触发异常的测试,那么您将成为您自己的客户并欣赏哪个更好。

如果很难测试错误条件,则可能是死机。但是任何参数验证错误都应该使用 croak。

于 2012-05-19T13:26:52.203 回答
0

Carp 例程在您自己的模块中很有用,因为它们的行为类似于 die() 或 warn(),但带有更可能对您的模块用户有用的消息。

https://perldoc.perl.org/Carp

于 2021-01-13T16:54:48.903 回答