@KeithDahlby posted a good question for thought the other day on “the” Twitter:

When implementing the Observer pattern, how do you handle exceptions from observers?

This seemingly harmless question should spark at least a good 15 minute debate.  An obvious question (and the one I asked):

Do you care if an observer throws an exception?

If you consider the classic observer pattern you’ll note that the observed only knows about it’s observers through an interface.  Using an interface for observers to reduce coupling is a good practice but by doing that you’ll want to be sure to retain that reduction of coupling by not allowing the observed to know about any of the concrete observers. 

Deciding to allow the observed to know about it’s observers and allow it to handle exceptions would introduce coupling that could lead to bugs down the road. 

Keith is a super smart guy and knew all along what to do, but the “what” is icky:

That’s what we’re doing, but agreed that it’s icky – wish there were a better option that catch(Exception)

This is icky because in the event an observer is very broken you won’t have a first-hand way to find out (and ReSharper will let you know about the dangers of your empty catch block).  Each observer is now responsible for logging or notifying someone about exceptions which adds some additional complexity (possibly through configuration or another mechanism).

You’ll run into these icky decisions and each one certainly needs healthy debate and some documentation to cover the bases later on when someone might question why the icky option was chosen. 

What was your most recent “icky” situation?