我发现在链接类函数方面有一些限制,比如说$class->setUser('foo')->getInfo()
(错误的例子),尽管我很难理解如何处理链中其中一个调用引起的任何错误。
例如,如果setUser()
出现错误并返回false,则不会返回$this
并且不允许调用其他函数,从而显示错误。
我实际上刚刚意识到(如果这是错误的话,请纠正我),如果setUser()
中有错误阻止以下getInfo()
函数运行并发出错误,会抛出异常吗?
这至少有用的知识,所以我可以调试使用链接的代码,即使我不使用它。
答案 0 :(得分:3)
是的,在这种情况下抛出异常可能是一个好主意。您将能够确定链中发生错误的位置。
以下是一个如何运作的例子:
try
{
$class->setUser('foo')->getInfo();
}
catch(UnknownUser $ex)
{
// setUser failed
}
catch(CannotFetchInfo $ex)
{
// getInfo failed
}
答案 1 :(得分:1)
与任何链条一样:如果一个元素被破坏,整个链条就会被打破。
因此,如果您正在链接对象,一方面这可能非常容易访问,另一方面如果由于错误(例如远程连接,文件等)而导致事件失败,则链接变得笨拙。
因此,除非事情没有返回预期的响应类型但发出失败的信号,否则异常可能会有所帮助,但由于链条被破坏 - 使用有限。
但是,我认为抛出异常是您可以为错误处理做的最好的事情(在和链中开发自己的代码)。
抛出异常的好处如下:您不需要破坏使链可访问的语法。
假设您在代码中出错了。最好抛出一个Exception,因为你需要修复它。
或者说,数据层已被编码为太频繁失败。抛出异常,然后你知道需要更多爱的部分。
在具有链接的通用代码中,这些exceptions会打断你(你可以随时抓住它们,然后你可以turn errors into exceptions as well),但它们会指出你的原因你可能还没有想过的错误。
所以,
无论链接的完成程度如何,都会让它不再有意义(我应该添加“和所有内容一样”;))。我不会说我是一个真正的链接迷,但即使作为一个非狂热的我也不时在我自己的代码中使用这个原则。它可以创建易于编写的代码,因此使用异常进行错误处理,我没有遇到任何“真正的”(tm)问题。这比用这样的虚假或废话打破链条要好得多。
理论上你可以通过重载返回一个接受任何属性/成员调用set / get的对象,但即使这很有趣,我认为它只会引入更多的复杂性而不是它有助于处理实际的现实生活错误。
因此,如果您链接到错误,实际上在使用异常时会看到错误。这就是例外情况:由于错误(或信号也起作用)中断应用程序的标准处理。