问题:
什么被认为是"最佳实践" - 以及为什么 - 在构造函数中处理错误？
"最佳实践"可以引自施瓦茨,或50%的CPAN模块使用它等等; 但我对任何人都有充分理由的意见感到高兴,即使它解释了为什么常见的最佳实践并不是真正的最佳方法.
至于我自己对该主题的看法(通过Perl中的软件开发多年来了解),我在perl模块中看到了三种主要的错误处理方法(在我看来从最好到最差列出):
构造一个对象,设置一个无效的标志(通常是" is_valid"方法).通常通过类的错误处理与设置错误消息相结合.
优点:
允许标准(与其他方法调用相比)错误处理,因为它允许$obj->errors()在错误的构造函数之后使用类型调用,就像在任何其他方法调用之后一样.
允许传递其他信息(例如> 1错误,警告等...)
允许轻量级的"重做"/"fixme"功能,换句话说,如果构造的对象非常繁重,许多复杂的属性100%总是正常,并且它无效的唯一原因是因为某人输入了不正确的日期,你可以简单地做" $obj->setDate()"而不是再次重新执行整个构造函数的开销.这种模式并不总是需要,但在正确的设计中非常有用.
缺点:没有我知道的.
返回" undef".
缺点:无法实现第一个解决方案的任何优点(全局变量之外的每个对象错误消息和重型对象的轻量级"fixme"功能).
死在构造函数内部.在一些非常狭窄的边缘情况之外,我个人认为这是一个可怕的选择,有太多理由列出这个问题的边缘.
更新:为了清楚,我认为(非常有价值和一个伟大的设计)解决方案有一个非常简单的构造函数,它根本不会失败,而且是一个繁重的初始化方法,其中所有错误检查都只是其中任何一个的子集出于此问题的目的,情况#1(如果初始化程序设置错误标志)或情况#3(如果初始化程序死亡).显然,选择这样的设计,你会自动拒绝选项#2.