Observer模式的常見錯誤處理機制是什麼？

Question

我正在學習設計模式，並且我在Observer模式的所有示例實現中注意到的一件事情是，在Subject的註冊/註銷方法中沒有真正的錯誤處理。這讓我想知道如何做到這一點。

如何具體處理錯誤將取決於應用程序的需求，但什麼是處理那種錯誤的常用方法？

例如，我嘗試註冊的觀察，但註冊失敗。那個錯誤是否只是悄無聲息地發生，那個特定的觀察者不會得到更新是可以接受的？主題不是我想的更明智，可以繼續通知觀察員DID已成功註冊。

我發現我有時也很難判斷多少錯誤檢查是如何足夠的程序，並且不知道這是那些我在想每一偶發案件之一。

Answer 1

如果註冊觀察器失敗，您肯定應該提出一些錯誤。您的代碼的客戶希望得到關於主題變化的通知，並且在他無法做到這一點時必須能夠做出反應。但未註冊一名觀察員不應影響其他觀察員的主題和。事實上，你甚至可能有一個觀察員失敗的觀察員註冊事件 - 元觀察員;-)。

但更有趣的方面恕我直言，是當觀察其notify方法中拋出一個異常，會發生什麼？其他觀察員是否應該打電話？該觀察員是否應該註銷？誰對這個錯誤負責？並在哪裏處理？

解決此問題的其他設計模式很少。你可以使用Decorator幷包裝每個Observer捕獲從notify拋出的異常併吞下它們（ekhem，logging）。主體甚至不會注意到，這很好。另外，其他觀察者不會因爲異常被發現得早，而被打亂。

另外考慮Composite將所有Observers包裝成一個單一的虛擬之一。然後將其裝飾成上述異常捕捉觀察者。看起來很相似，但從一個觀察者拋出的異常會阻止進一步的觀察者被調用。現在，你甚至可以形成層次...

Answer 2

通知處理程序從觀察者真的應該幾乎從來沒有泄漏的異常，因爲這通常是最感興趣的一個異常的惟一實體是的投擲它的觀察者。實質上，一個例外通常意味着「我不能做你要求的，因爲X」。一個可觀察的主體通常不會在意事件處理程序做任何事情，因此如果他們不這樣做，他們也不在乎。另一方面，如果一個例外意味着主體的類不變量不再被滿足，那麼例外可能是一個必要的罪惡。

如果異常是從一個通知處理程序拋出，應該很認真地認爲（如果它是不應該被夾在處理一些圓頂愚蠢的事，應該認真地固定）。然而，在拋出異常的第一個事件處理程序之後跳過所有事件處理程序的正常Microsoft事件模式是非常糟糕的事件。一個更好的方法是運行所有事件處理程序，捕獲發生的所有異常並將它們添加到列表中，然後在最後如果列表不爲空，則引發EventHandlerException，其中包含所有異常的列表在處理事件時發生。