Are event subscribers called in order of subscription?

Question

Is it safe to assume that event subscribers are called in order of subscription?
Example:

void One(object sender, EventArgs e) {}
void Two(object sende         


        

Answer 1

In general, events subscribers are expected to behave independently from each other. It should make no difference whether they're invoked in order of subscription, reverse order of subscription, or in seemingly-random order which varies arbitrarily each time the event is raised. Subscribers shouldn't care about other subscribers that execute before them or after them.

In some cases, however, events may be used in contexts where such ordering is important. Event handlers may be passed a mutable object, and be expected to make use of previous handler's mutations of that object. In such a case, if meaningful operation of the events would require that they be performed in a particular order, and provided that any documented requirements for subscribers have been complied with, one should expect that the events will be executed in the order given.

Answer 2

Pay very close attention to the caveats given by Jon Skeet - "Given that implementation...". In other words, make the slightest change (multiple threads, other handlers, etc.) and you risk losing the order-of-execution invariance.

Do NOT rely on event ordering. All event dispatches should be logically independent, as if they were occurring in parallel. Events are logically independent actions.

I'll go one step further, and assert that if you have to assume an order for events firing, you have a serious design flaw and/or are misusing events.

Answer 3

The quick answer would be "It's none of your business" :)

An event is asynchronous by nature. This means that you are not waiting for an event to be fired or expecting it to occur at a given time. They just happen and then you take action. Wanting to know 'when' or trying to figure out 'how' is going to break this nature.

Maybe in this case you don't need an event-based approach to get things done?

What Jon Skeet said is technically correct for the current implementation, but maybe it won't in c#8.5 or VBasic 15.0. Relying on implementation details is always going to do more harm than good.

Answer 4

Given that implementation, yes, they will always be called in that order.

If the event actually uses some weird and wonderful way of handling subscriptions, it could do different things - but "normal" implementations will do the right thing.

To be clear, subscribing to an event handler just means invoking the appropriate "add" part of an event. If the event handles this by doing something like:

myHandler += value;

that gets translated into

myHandler = Delegate.Combine(myHandler, value);

and Delegate.Combine guarantees the ordering. However, if you had an event like this:

private LinkedList<EventHandler> eventHandlers = new LinkedList<EventHandler>;

public event EventHandler Foo
{
    add
    {
        eventHandlers.AddFirst(value);
    }
    remove
    {
        // do stuff here too
    }
}

and then fired the event by doing something like:

foreach (EventHandler handler in eventHandlers)
{
    handler(this, EventArgs.Empty);
}

then the handlers would be called in the reverse order.

Summary: For all sane events, you can rely on the ordering. In theory, events can do what they like, but I've never seen an event which doesn't maintain the appropriate ordering.

Answer 5

Even if they are called in the correct order I would try to not write code that relies on a previous delegate having been fired for it to function correctly.

If Two() is dependant on something that One() is doing then either attach a single delegate that calls the two methods in the correct order, or have Two() invoke One() when necessary.