当 Perl 中发生不好的事情时，是 croak() 还是 die() 更好？
perlcritic 抱怨以下代码，一些样板 DBI 内容工作得很好，应该 croak 而不是 die：
# Connect to database
my $db_handle = DBI->connect( $url, $user, $password ) or die $DBI::errstr;
所有这些，而 die 似乎对我来说工作得很好。
我认为对于一个武士 Perl 战士来说，当事情出错时，呱呱叫比实际死亡更不光荣。笑话分开
为什么我应该呱呱而不是死？
不听取 perlcritic 建议的后果是什么？
perlcritic complaints that the following code, some boilerplate DBI stuff that works perfectly fine, should croak instead of die:
# Connect to database
my $db_handle = DBI->connect( $url, $user, $password ) or die $DBI::errstr;
All this, while die seems to work fine for me.
I would think for a samurai Perl warrior, croak is less honorable than actually die when things go awry. Jokes apart
Why should I croak instead of die?
What are the consequences of not heeding perlcritic's advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
来自 http://www.perlmonks.org/?node_id=685452
在这种情况下，错误（与数据库的连接错误）与调用者无关，而与建立连接的线路有关，因此我将使用die。
From http://www.perlmonks.org/?node_id=685452
In this case, the error (connection error to DB) has nothing to do with the caller and everything to do with the line making the connection, so I would use
die.我通常使用以下内容：
die "string"来表示您想要直接传达给用户的致命消息。我主要在脚本中执行此操作。die $object，尽管大多数异常类都会有throw方法为您执行此操作。这是为了当你的调用者应该能够知道你抛出了什么样的错误，甚至可以从中提取信息。如果您使用的是 Moose，请查看 Throwable 和 Throwable-X< /a>croak "message"就像 Adrian 所说的那样，当你的用户做了错事，并且你想在任何调用你的代码的地方报告错误时。函数和 API 级方法是这种情况的常见情况。承认“消息”。这些通常是您认为是错误的运行时错误，而不是异常情况。对这些使用异常是有意义的，特别是如果您有一个已经使用异常的大型项目。但这是获取错误堆栈跟踪的好方法。I usually use the following:
die "string"for fatal messages you want to directly communicate to the user. I mostly do this in scripts.die $objectfor full blown exception objects, although most exception classes will havethrowmethod doing that for you. This is for when your caller should be able to tell what kind of error you throw, and maybe even extract information out of it. If you're using Moose, check out Throwable and Throwable-Xcroak "message"like Adrian said is for when your user has done something wrong, and you want to report the error at whatever called your code. Functions and API level methods are usual cases for this.confess "message"for library errors where I don't see the usefulness of an exception yet. These are usually runtime errors you assume to be a mistake, rather than an exceptional condition. It can make sense to use exceptions for these, especially if you have a large project that uses exceptions already. But it's a good, nice and easy way to get a stacktrace with the error.如果我们在函数外部调用 die 和 croak，则没有
这些功能之间的区别。
只有当我们在任何情况下调用 die 和 croak 时，我们才能发现差异。
其他功能。
croak 将提供有关调用者的信息，例如函数名称
和行号..等。
die 会给出错误并给出发生错误的行号。
If we called the die and croak outside the function there is no
difference between these functions.
We can only find difference when we call die and croak within any
other function.
croak will gives information about the caller such as function name
and line number..etc.
die will give error and gives the line number where the error has occured.
使用
die()不一定是错误的，但croak()可以为您或您的用户提供更多有关问题所在的信息。还可以在 Carp 命名空间中设置一些变量，这些变量可以更改此输出以获取更多或更少的信息。它相当于
die()但具有更多信息和控制。It's not necessarily wrong to use
die()butcroak()gives you or your user a lot more information about what went wrong. There's also variables that can be set in theCarpnamespace that can change this output to get more or less information.It's equivalent to
die()but with more information and control.仍然。如果连接参数如其他人指出的那样直接来自函数的输入，则此示例可能需要使用 croak。
如果您为自己编写一个触发异常的测试，那么您将成为自己的客户并欣赏哪个更好。
如果测试错误条件非常困难，则可能会出现死机的情况。但任何参数验证错误都应该使用 croak。
Still. This example may want to use croak if the connection parameters came directly from the inputs to the function as others pointed out.
If you write a test for yourself that triggers the exception then you will be your own client and appreciate which is better.
If it is very hard to test error condition it may be a case for die over croak. But any parameter validating errors should use croak.
https://perldoc.perl.org/Carp
https://perldoc.perl.org/Carp