Are event subscribers called by subscription?

Question

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

void One(object sender, EventArgs e) {} void Two(object sender, EventArgs e) {} event EventHandler foo; foo += One; foo += Two; 

Is One () always called before Two () when the event fires?

Edit:
You should, of course, not rely on it, I just thought. The idea was that the multicast delegates are similar to the COMMAND pattern. So I'm just curious. Usually you used a collection that keeps order for COMMANDs so you can do undo / redo / whatever.

Answer 1

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

If the event does use some weird and wonderful way to process the subscription, it can do different things, but the “normal” implementations will do the right thing.

To be clear, subscribing to an event handler means only accessing the corresponding “added” part of the event. If the event handles this, doing something like:

 myHandler += value; 

which translates to

 myHandler = Delegate.Combine(myHandler, value); 

and Delegate.Combine guarantees the order. However, if you had such an event:

 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 will be called in the reverse order.

Summary For all reasonable events, you can rely on ordering. Theoretically, events can do what they like, but I have never seen events that do not support the proper order.

Answer 2

Pay particular attention to the warnings given by John Skeet - "Given this implementation ...". In other words, make the slightest change (multiple threads, other handlers, etc.), and you risk losing the invariance of the execution order.

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

I will take it one step further and claim that if you have to accept an order for shooting events, you have a serious design flaw and / or abuse the events.

Answer 3

Even if they are called in the correct order, I will try not to write code that relies on the previous delegate who was fired to make it work correctly.

If the Two () function depends on what One () does, then either attach one delegate that calls two methods in the correct order, or has two () if necessary, to call One ().

Answer 4

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

An event is asynchronous in nature. This means that you do not expect the event to be fired or is expected to happen at a given point in time. They just happen, and then you take action. The desire to know the "when" or try to find out how the "how" will violate this nature.

Maybe in this case you do not need an event-based approach to get everything done?

What John Skeet said is technically correct for the current implementation, but it may not be in C # 8.5 or VBasic 15.0. Reliance on implementation details will always do more harm than good.

Answer 5

In general, it is expected that event subscribers will behave independently of each other. It doesn’t matter if they are called in subscription order, in reverse subscription order, or in seemingly random order, which changes randomly every time an event occurs. Subscribers should not care about other subscribers that run before or after them.

In some cases, however, events can be used in contexts where such ordering is important. Event handlers can be passed by a mutable object and, as expected, will use the previous processor handles of this object. In this case, if significant work of the events requires that they be carried out in a certain order and subject to any documented requirements for subscribers, it should be expected that the events will be executed in the specified order.