我发现在链接类函数（比如$class->setUser('foo')->getInfo()（坏例子））中有一些有限的用途，尽管我很难理解如何处理链中某个调用产生的任何错误。
例如，如果setUser()出现错误并返回false，它将不会返回$this，也不允许调用另一个函数，从而显示错误。
事实上，我刚刚意识到（如果这是错误的，请纠正我），如果setUser()中出现错误，抛出异常会阻止以下getInfo()函数运行并发出错误吗？
这至少是有用的知识，这样我就可以调试使用链接的代码，即使我不使用它。
下面是一个如何工作的例子：
try
{
$class->setUser('foo')->getInfo();
}
catch(UnknownUser $ex)
{
// setUser failed
}
catch(CannotFetchInfo $ex)
{
// getInfo failed
}
与任何链一样：如果一个元素被破坏，整个链就会被破坏。
因此，如果您正在链接对象，一方面这可能非常容易访问，另一方面，如果由于错误（例如远程连接、文件等）导致事情往往失败，则链接会变得尴尬。
因此，除非事情没有返回预期类型的响应，而是发出失败的信号，否则异常可能会有所帮助，但随着链的断裂，其用途有限。
然而，我认为抛出异常是错误处理（在和的链中，用于开发自己的代码）所能做的最好的事情。
抛出Exception的好处如下：您不需要破坏使链可访问的语法。
假设您在代码中犯了一个错误。最好抛出一个Exception，因为无论如何都需要修复它。
或者假设数据层已经被编码为它经常失败。抛出一个例外，你就会知道需要更多爱的部分。
在具有链接的通用代码中，这些异常会打断您（您可以随时捕捉它们，顺便说一句，您也可以将错误转化为异常），但它们会指出您可能还没有充分考虑的错误原因。
所以，
- 异常是链错误处理的一种方式
- 异常可以帮助您定位各种错误源，同时可以维护链语法以实现更高级别的数据访问
然而，不管链接做得有多好，它都会变得不再有意义（我应该加上"一切都一样"；）。我不会说我是一个真正的链接粉丝，但即使作为一个非粉丝，我也会在自己的代码中不时地使用这个原则。它可以创建易于编写的代码，所以要利用异常来处理错误，我没有遇到任何"真正的"（tm）问题。这比用一个错误或类似的垃圾来破坏你的链要好得多。
理论上，你可以通过重载返回一个接受任何属性/成员调用集/get的对象，但即使这很有趣，我认为它只会引入比处理实际错误更复杂的复杂性。
因此，如果你链接到一个错误中，当你使用异常时，你实际上会看到错误。这就是例外情况：由于错误（或信号也有效）而中断应用程序的标准处理。