CODEWITHSUNDEEP
design-patternserror-handlingobserver-pattern
user331006
user331006

Reputation:

What are the common error handling mechanisms for the Observer pattern?

I'm learning about design patterns and one thing I noticed in pretty much all the example implementations of the Observer pattern is that there isn't really any error handling in the Subject's register/unregister methods. This got me wondering how / if this is done.

How specifically to handle errors will depend on the application's needs but what are the common ways to handle that sort of error?

For example, I try to register an Observer but the registration fails. Does that error just silently occur and it's acceptable that that particular Observer just won't get updates? The Subject is none the wiser I guess and can carry on notifying the Observers that DID successfully register.

I've noticed I sometimes have a hard time judging how much error checking is enough in a program and wonder if this is one of those cases where I'm over thinking every contingency.

Upvotes: 6

Views: 2074

Answers (2)

supercat
supercat

Reputation: 81123

Notify handlers from observers really should almost never leak exceptions, because the only entity that would normally be most interested in an exception is the observer that's throwing it. An exception normally means, in essence, "I couldn't do what you requested because X". An observable subject generally won't care that event handlers do anything, so thus wouldn't care if they fail to do it. On the other hand, if an exception means that the subject's class invariants are no longer met, then an exception is probably a necessary evil.

If an exception is thrown from a notify handler, it should be regarded pretty seriously (if it's some dome stupid thing that shouldn't have been caught in the handler, that should seriously be fixed). The normal Microsoft event patter of skipping all event handlers following the first one that throws an exception is however a very bad one. A much better approach would be to run all event handlers, capturing all exceptions as they occur and adding them to a list, and then at the end, if the list isn't empty, throwing a EventHandlerException which contains a list of all exceptions that occurred while processing the event.

Upvotes: 0

Tomasz Nurkiewicz
Tomasz Nurkiewicz

Reputation: 340713

If registering the Observer fails, you should definitely raise some error. The client of your code expects to be notified about changes in the Subject and it must be able to react when he is not able to do this. But failing to register one observer shouldn't affect both Subject and other Observers at all. In fact, you might even have an observer for failed observer registration events - meta-observer ;-).

But much more interesting aspect IMHO is what should happen when Observer throws an exception from within its notify method? Should the rest of observers be called? Should this observer be deregistered? Who is responsible for this error? And where to handle it?

There are few other design patterns that address this issue. You might use Decorator and wrap each and every Observer catching exceptions thrown from notify and swallowing them (ekhem, logging). The Subject won't even notice, which is fine. Also, other Observers won't be disrupted because the exception is caught early enough.

Also consider Composite to wrap all the Observers into a single, virtual one. Then decorate this into aforementioned exception catching observer. Seems similar but exception thrown from one observer will prvent further observer being called. Now you can even form hierarchies...

Upvotes: 2

Related Questions