Perl - 处理传递给子的无效数据的最佳实践

Question

当数据被错误地传递给子例程时，Perl 中的最佳实践是什么？潜艇应该死掉还是返回？

这是我通常做的事情

my @text = ('line 1', 'line 2');

print_text(\@text) 
   or die "ERROR: something went wrong in the sub";

sub print_text{
   my ($aref_text) = @_;
   return unless ref($aref_text) eq "ARRAY";
   print "$_\n" for @{$aref_text};
   return 1;
}

如果传递的输入无效并且它希望调用者像这里一样检查错误，那么这里 sub 只会返回。我想知道在子级别“死”是否总是更好的做法。在大脚本中，我害怕这样做，因为我不想仅仅因为一些简单的子失败而杀死整个脚本。

另一方面，我害怕只是返回，因为如果调用者忘记检查 sub 是否返回 true，那么脚本将继续运行，并且可能会发生奇怪的事情。

谢谢

Answer 1

这完全属于如何处理子程序中的错误的问题。

原则上，这些是处理子程序错误的方法

• 返回代码，其中一些表示错误

• 返回“特殊”值，例如 Perl 中的 undef

• 抛出异常，Perl 中的设备是die

调用者要么检查返回，要么测试undef，或者使用eval 来捕获和处理die。什么最合适完全取决于上下文和代码的作用。

我认为现代语言没有太多理由被限制为指示错误的“代码”（如负值）。一方面，要么干扰合法返回，要么限制它们通过指针/引用进行，这是一个重大的设计决策。

返回undef 通常是一种很好的折中方法，尤其是在不太复杂的代码中。它表明子系统的某些“失败”无法执行其应做的事情。但是，即使在最小的 subs 中，undef 也可能适合指示不可接受的结果。那么如果它也被用于错误的输入，我们就会有区分这些失败的问题。

基于简单的die 在Perl 中引发异常，增加了更多可能性。在复杂的代码中，您可能希望编写（或使用）一个错误处理类，该类模仿具有它的语言的异常处理支持，然后抛出它。

my $error_obj = ErrorHandlingClass->new( params );

... or die $error_obj;

然后调用代码可以分析对象。这将是最结构化的方式。

Path::Tiny 是一个不错且简单的示例，在其 source 中可以找到自己的 Path::Tiny::Error。

同样，适合任何特定情况的方法取决于该应用程序的详细信息。

---

一些关于直接问题的问题。

die 中的无信息消息强调了返回什么的困境（它没有告诉我们失败的原因）。但是在这种情况下，我们如何使失败信息丰富呢？

请注意，如果 sub 返回 0 或空字符串，您的 or 会生成 die。如果我们将其替换为//（定义或），那么对于undef 上的die，如果undef 也可能指示错误结果，我们仍然无法打印特定消息。

因此，在这种情况下，您可能希望函数在输入错误时使用die，并带有合适的消息。

这将在出现问题后进行调试。如果代码需要能够恢复，那么您最好返回更多结构化信息——抛出（或返回）您要编写的错误处理类的对象。 （作为临时的权宜之计，您可以解析来自die 的消息。）

关于检查退货的古老纪律问题，die 是一个很好的工具。没有“simple sub”是不值得的——你不想继续出错，所以可以die。而在复杂的项目中，错误处理更加复杂，因此我们需要更多工具和结构，而不是更少。

回想一下，异常“冒泡”，如果未处理，则向上传播调用堆栈，die 也是如此。这可以很好地用于调试，而无需在每次调用时都使用eval。最后，大部分都是调试的一部分。

对此没有“最佳实践”。但是默认die-ing 还是比较合理的。