This is bad. The observer pattern (which is what events are) is about never having to care if you have 0, 1 or more subscribers. If you hace logic that cares, it is broken almost certainly…..

Why? Because ‘you will never know’ in a real framework environment if/how many/etc. about who is listening at any given moment to your events. You always have to assume there could be nobody.

One interest caveat: Do you have unrecoverable cases where you simply cannot continue if there are no subscribers to any given event?

For this case it is dangerous ground. I would encourage a rethink of the design. For example, (and this happens far too often in Silverlight due to the async nature of it) I have a few background activities which are retrieving the initialization data for my app. I have no idea when this will all be done exactly so I have a method of raising an event when ‘the bare minimum’ is done.

I AM the one subscribing to the framework events (the WebClient download string/stream callbacks for example) not my ‘client’ who is waiting on the result.

So I expost an event called ‘InitializationComplete’. I introduced a regression and it is not subscribed.

So I sink MY events and get the result. The data is there and I raise my event (blissfully not knowing if anyone is on the other end).

So what happens?????

In my opinion there would need (in any case) to be a reasonable timeout defined. This is on ‘my client’s’ code. So when it is done with all it needs to do and is basically now waiting for this event, it should not be forever.

In this case it will timeout. HOWEVER, it is easier to debug and you immediately know the issue if that null check is performed..

Hmm…. I guess this is one for ‘personal preference’? Thoughts?

Damon

Thanks !