C# events and class hierachy

Question

I have the following classes

Child class:

public class ChildClass
{
   ...
   private void EventHandler(...);
   ...
}

Parent class:

public class ParentClass
{
   ...
   ChildClass child;
   ...
   private void EventHandler(...);
   ...
}

Both of them have an event handlers on the same event.

The question is in which order those handlers will be called?

@UweKeim: Using the debugger you can find out what *happens* to be the current implementation. Referencing the docs you can learn what is the *guaranteed* behavior. — Jon, Mar 20 '13 at 13:11
If you are relying on the order of invocation of the handlers of an event you're doing something wrong, from a design perspective. If one handler should run after another then it should be invoked from that other event handler, not from the same event source. — Servy, Mar 20 '13 at 14:16

score 6 · Accepted Answer · edited May 23 '17 at 11:45

Important note

Servy has very correctly pointed out that we cannot rule out the possibility that the event in question is owned by a third party and it implements the accessors itself. If that is the case then all bets are off.

The original answer below silently assumes that we are talking about a bog-standard, totally uninteresting event implementation.

Original answer

Events are implemented through delegates.

From MSDN:

A useful property of delegate objects is that multiple objects can be assigned to one delegate instance by using the + operator. The multicast delegate contains a list of the assigned delegates. When the multicast delegate is called, it invokes the delegates in the list, in order.

So the handlers are invoked in the order that you add them to the event.

Events *can* be implemented through delegates, but there is nothing *forcing* events to be implemented through delegates. For an event not implemented through a delegate the invocation order could be something entirely different. — Servy, Mar 20 '13 at 14:20

score 3 · Answer 2 · answered Mar 20 '13 at 13:09

3

The order in which the delegates are subscribed to, although since it's not properly noted anywhere in the specification (that I know of) that this is expected behaviour, specifically, then relying on such order could be folly, as it could change per implementation.

answered Mar 20 '13 at 13:09

Grant Thomas

44,454
10
85
129

1

It is noted in the docs, so it most certainly could **not** change -- at least any more than e.g. Microsoft could decide that starting tomorrow, (put your preferred method here) will be taking its arguments in a different order. Instant breakage of previously-working code throughout the world = not something you do if it can be avoided at all. – Jon Mar 20 '13 at 13:14
@Jon Unless a collection of things is explicitly documented to be in reliable, predictable order, then it can't be trusted; this is, in fact, mentioned in your answer so there's little risk (in an MS implementation), but this _kind_ of expecation has been known to sting people before. – Grant Thomas Mar 20 '13 at 13:23
My point is that it *is* explicitly documented. If you know the order in which the handlers are wired up, you also know the order they will be invoked in. – Jon Mar 20 '13 at 13:26
@Jon Do you have a reference to where this is an implementation independent expectation? – Grant Thomas Mar 20 '13 at 13:27
1

In two parts: a) [events are implemented with delegates](http://msdn.microsoft.com/en-us/library/edzehd2t.aspx), b) the only method that can "add" delegates [explicitly specifies](http://msdn.microsoft.com/en-us/library/30cyx32c.aspx) the order of delegates in the resulting multicast delegate. If someone (e.g. Mono) does it differently, then their implementation is clearly not conformant. – Jon Mar 20 '13 at 13:38
@Jon That's how it _is_ implemented, not the specification to implement from, to be fair. People doing Mono would not be using MSDN documentation by default, because, well obviously (in many cases they _could_ but that's a different thing). I understand your point, and I'm not saying you're wrong or being confrontational, I'm legitimately curious: Is their any explicit detail between MS and ECMA specs, for example? – Grant Thomas Mar 20 '13 at 13:43
I appreciate the discussion, and also do not wish to be confrontational. To be fair, I think the definitive resource would be the CLI spec, but a quick browsing of a copy I just downloaded from ISO does not mention such things at all. Of course this translates to arrows in your own quiver. ;-) – Jon Mar 20 '13 at 13:52
2

@Jon That assumes the event uses a multicast delegate as the backing storage. If the event doesn't use the built in add/remove methods and instead provides it's own it can use whatever storage mechanism it wants, and it may or may not maintain the same ordering. Since this is an *event* and not a *delegate* the order of invocation can in fact change without needed a change in the language specs or implementation, merely a modification of the definition of that class. – Servy Mar 20 '13 at 14:15
@Servy: Sure. Obviously if it's your own event then you are the authority on how that works, but it's true that the OP did not explicitly say it is their own event. I 'll go and amend my answer. – Jon Mar 20 '13 at 14:18
@Jon Even if it's not their own event, if it's any event that has been written to use custom add/remove handlers it could have any number of possible behaviors, including concurrent invocation, some other order of invocation, etc. It's not common, but existing events with that behavior exist, so relying on any given event to have this behavior is something you can't do. – Servy Mar 20 '13 at 14:22

score 3 · Answer 3 · answered Mar 20 '13 at 13:10

3

it will be called int the order they are registered.

answered Mar 20 '13 at 13:10

Kajal

223
4
15

score 3 · Answer 4 · edited Mar 20 '13 at 13:41

While the MSDN documentation clearly states that the multicast delegates invokes the delegates in the order in which they subscribed, that assumes that the subscription order is deterministic, i.e. that you are in a single-threaded environment.

If that is not the case, you may be better off defining two events: a BeforeEventOccurs event and an AfterEventOccurs event. This will give you deterministic control over the order even in a multi-threaded environment.

score 2 · Answer 5 · edited May 23 '17 at 10:25

2

According to this question event handlers get called in the order they are subscribing to the event.

edited May 23 '17 at 10:25

Community

1
1

answered Mar 20 '13 at 13:09

Carsten

11,287
7
39
62

score 1 · Answer 6 · answered Mar 20 '13 at 13:10

From Delegates

Delegates are used to pass methods as arguments to other methods. Event handlers are nothing more than methods that are invoked through delegates. You create a custom method, and a class such as a windows control can call your method when a certain event occurs.

From How to: Combine Delegates (Multicast Delegates) page;

A useful property of delegate objects is that multiple objects can be assigned to one delegate instance by using the + operator. The multicast delegate contains a list of the assigned delegates. When the multicast delegate is called, it invokes the delegates in the list, in order.

C# events and class hierachy

6 Answers6