perl - Perl 构造函数应该返回 undef 还是 "invalid"对象？

Question

问题 :

什么被认为是“最佳实践” - 为什么 - 在构造函数中处理错误？

“最佳实践”可以是 Schwartz 的引述，或者 50% 的 CPAN 模块都使用它，等等……；但我对任何人的合理意见感到满意，即使它解释了为什么常见的最佳实践并不是真正的最佳方法。

就我自己对该主题的看法(多年以来受 Perl 软件开发的启发)，我已经看到了在 perl 模块中处理错误的三种主要方法(我认为从最好到最差列出):

构造一个对象，设置一个无效标志(通常是“is_valid”方法)。通常与通过类的错误处理设置错误消息相结合。

优点:

允许标准(与其他方法调用相比)错误处理，因为它允许使用 $obj->errors()在错误的构造函数之后进行类型调用，就像在任何其他方法调用之后一样。

允许传递附加信息(例如 >1 错误、警告等...)

允许轻量级的“redo”/“fixme”功能，换句话说，如果构造的对象非常重，具有许多复杂的属性，100% 总是可以的，它无效的唯一原因是因为有人输入了一个日期不正确，您可以简单地执行“$obj->setDate()”，而不是再次重新执行整个构造函数的开销。这种模式并不总是需要，但在正确的设计中非常有用。

缺点:据我所知没有。

返回“undef”。

缺点:无法实现第一个解决方案的任何优点(全局变量之外的每个对象错误消息和重对象的轻量级“fixme”功能)。

在构造函数中死掉。除了一些非常狭窄的边缘情况之外，我个人认为这是一个糟糕的选择，原因太多，无法在这个问题的边缘列出。

更新:为了清楚起见，我认为(否则非常值得和一个伟大的设计)解决方案具有非常简单且根本不会失败的构造函数和一个繁重的初始化方法，其中所有错误检查都只是其中之一的一个子集出于本问题的目的，案例#1(如果初始化程序设置错误标志)或案例#3(如果初始化程序死亡)。显然，选择这样的设计，你会自动拒绝选项 #2。

Answer 1

这取决于您希望构造函数的行为方式。

此回复的其余部分属于我个人的观察，但与 Perl 的大多数事情一样，最佳实践真正归结为“这是一种方法，您可以根据需要采取或离开。”你所描述的偏好是完全有效和一致的，没有人应该告诉你。

实际上，如果构造失败，我宁愿死掉，因为我们设置它以便在对象构造期间可能发生的唯一类型的错误确实是大的，应该停止执行的明显错误。

另一方面，如果您不希望这种情况发生，我认为我更喜欢 2 而不是 1，因为检查 undefined object 与检查某些标志变量一样容易。这不是 C，所以我们没有强类型约束告诉我们构造函数必须返回这种类型的对象。所以返回 undef ，并检查以确定成功或失败，是一个不错的选择。

构造失败的“​​开销”是在某些边缘情况下的考虑因素(在产生开销之前你不能快速失败)，所以对于那些你可能更喜欢方法 1 的人。同样，这取决于你为对象定义的语义 build 。例如，我更喜欢在构造之外进行重量级初始化。至于标准化，我认为检查构造函数是否返回定义的对象与检查标志变量一样好。

编辑:作为对您对初始化程序拒绝案例 #2 的编辑的回应，我不明白为什么初始化程序不能简单地返回一个指示成功或失败的值，而不是设置一个标志变量。实际上，您可能希望同时使用这两种方法，具体取决于您想要了解所发生错误的详细信息。但是初始化器在成功时返回 true 和 undef 是完全有效的。关于失败。