Question

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.

Answer 1

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…