perlcritic抱怨以下代码，一些运行良好的样板 DBI 东西，应该croak代替die：
# Connect to database
my $db_handle = DBI->connect( $url, $user, $password ) or die $DBI::errstr;
所有这一切，而 die 似乎对我来说很好用。
我认为对于武士 Perl 战士来说，当事情出错时，呱呱叫声比实际死更不光彩。笑话分开
我为什么要croak代替die？
不听 Perlcritic 的建议会有什么后果？
来自http://www.perlmonks.org/?node_id=685452
当错误是您或您的代码没有正确执行时，您使用 die。当您的呼叫者做得不对时，您会使用 croak。死“错误：$！” 指示错误在发生错误的行上。呱呱“错误：$！” 表示错误出现在调用者调用您的代码的那一行。
在这种情况下，错误（与 DB 的连接错误）与调用者无关，与建立连接的线路有关，所以我会使用die.
我通常使用以下内容：
die "string"对于要直接与用户交流的致命消息。我主要在脚本中执行此操作。die $object对于完整的异常对象，尽管大多数异常类都会throw为您提供方法。这是为了当你的调用者应该能够判断你抛出了什么样的错误，甚至可能从中提取信息。如果您使用Moose，请查看Throwable和Throwable-Xcroak "message"就像阿德里安所说的那样，当您的用户做错了事，并且您想在任何调用您的代码时报告错误。函数和 API 级别的方法是这种情况的常见情况。confess "message"对于我还没有看到异常有用性的库错误。这些通常是您认为是错误的运行时错误，而不是异常情况。对这些使用异常是有意义的，特别是如果您有一个已经使用异常的大型项目。但这是获取错误堆栈跟踪的好方法。使用它不一定是错误的，die()但croak()可以为您或您的用户提供有关问题所在的更多信息。还可以在Carp命名空间中设置变量，这些变量可以更改此输出以获取更多或更少的信息。
它相当于die()但有更多的信息和控制。
如果我们在函数之外调用 die 和 croak，这些函数之间没有区别。
只有当我们在任何其他函数中调用 die 和 croak 时，我们才能发现差异。
croak 将提供有关调用者的信息，例如函数名称和行号..等。die 将给出错误并给出发生错误的行号。
仍然。如果连接参数直接来自其他人指出的函数的输入，则此示例可能要使用 croak。
如果您为自己编写一个触发异常的测试，那么您将成为您自己的客户并欣赏哪个更好。
如果很难测试错误条件，则可能是死机。但是任何参数验证错误都应该使用 croak。
Carp 例程在您自己的模块中很有用，因为它们的行为类似于 die() 或 warn()，但带有更可能对您的模块用户有用的消息。