Observer模式的常见错误处理机制是什么？

Question

我正在学习设计模式，并且我在Observer模式的所有示例实现中注意到的一件事情是，在Subject的注册/注销方法中没有真正的错误处理。这让我想知道如何做到这一点。

如何具体处理错误将取决于应用程序的需求，但什么是处理那种错误的常用方法？

例如，我尝试注册的观察，但注册失败。那个错误是否只是悄无声息地发生，那个特定的观察者不会得到更新是可以接受的？主题不是我想的更明智，可以继续通知观察员DID已成功注册。

我发现我有时也很难判断多少错误检查是如何足够的程序，并且不知道这是那些我在想每一偶发案件之一。

Answer 1

如果注册观察器失败，您肯定应该提出一些错误。您的代码的客户希望得到关于主题变化的通知，并且在他无法做到这一点时必须能够做出反应。但未注册一名观察员不应影响其他观察员的主题和。事实上，你甚至可能有一个观察员失败的观察员注册事件 - 元观察员;-)。

但更有趣的方面恕我直言，是当观察其notify方法中抛出一个异常，会发生什么？其他观察员是否应该打电话？该观察员是否应该注销？谁对这个错误负责？并在哪里处理？

解决此问题的其他设计模式很少。你可以使用Decorator并包装每个Observer捕获从notify抛出的异常并吞下它们（ekhem，logging）。主体甚至不会注意到，这很好。另外，其他观察者不会因为异常被发现得早，而被打乱。

另外考虑Composite将所有Observers包装成一个单一的虚拟之一。然后将其装饰成上述异常捕捉观察者。看起来很相似，但从一个观察者抛出的异常会阻止进一步的观察者被调用。现在，你甚至可以形成层次...

Answer 2

通知处理程序从观察者真的应该几乎从来没有泄漏的异常，因为这通常是最感兴趣的一个异常的惟一实体是的投掷它的观察者。实质上，一个例外通常意味着“我不能做你要求的，因为X”。一个可观察的主体通常不会在意事件处理程序做任何事情，因此如果他们不这样做，他们也不在乎。另一方面，如果一个例外意味着主体的类不变量不再被满足，那么例外可能是一个必要的罪恶。

如果异常是从一个通知处理程序抛出，应该很认真地认为（如果它是不应该被夹在处理一些圆顶愚蠢的事，应该认真地固定）。然而，在抛出异常的第一个事件处理程序之后跳过所有事件处理程序的正常Microsoft事件模式是非常糟糕的事件。一个更好的方法是运行所有事件处理程序，捕获发生的所有异常并将它们添加到列表中，然后在最后如果列表不为空，则引发EventHandlerException，其中包含所有异常的列表在处理事件时发生。