Why always use the longer EventHandler instead of Action for events

[Phoque]

I don’t know if there is a performance or cleanness reason for this, ot if it is a bad habit from me, but I really don’t like seeing EventHandlers for events, we have the way more practical Action / Func, so why use this class wich require you to add parameters even when you absolutely don’t use them?

[bixarrio]

CM says it early in the course: It’s the C# standard way. You don’t have to use it. I personally prefer using EventHandler for events.

PS. It’s not a good idea to use Func for events. While this is possible, only the last registered handler’s result will be returned, and there is no-way of knowing which it was. Unless you know that there’s only one. But Joe Teammate does not know this, and goes and adds another handler, and now the code doesn’t work as expected anymore

[Phoque]

So this is just personnal preference then?

Regarding Funcs I’m not sure I understand what you mean, to my knowledge they are exactly the same as Action except they return a value.
Do you mean there can be only one subscriber to a Func event? Cannot say for sure, but I think I already used Funcs with multiple subscribers before, so I don’t get what you meant

[CodeMonkey]

Yup the reason is simply because it’s the C# standard. Events just require a delegate type so it works just fine with a simple Action, if you prefer that go ahead and use it.

Although not with a Func since events are not supposed to return data so I’m not sure if you can even use it with Func, the Event listeners just listen, they’re not supposed to automatically send data back to the subscriber.

[Phoque]

Oh yeah makes sense, thank you I got the problem with Func events now

[Brian_Trotter]

There are, of course, several different types you can use for events.

• You could create a custom delegate, although once Microsoft introduced the System.Action classes, custom delegates sort of became unnecessary.
• You can use System.Actions. These are nice if you don’t need to know who specifically called the event, which makes them not as ideal for static events (you can always do an event Action<MyClass> for this, but it’s not quite as elegant as an EventHandler. The advantage of a System.Action is that it’s generally easier to implement and invoke compared to an EventHandler.
• In Unity, you can just declare a UnityEvent, which is the only official way of putting the event into the inspector. Subscribing to a UnityEvent is a bit different from the generic event, as you have to use AddListener() and RemoveListener() instead of += or -=
• You can use the EventHandler class. This, I believe, is the first of our courses to use the EventHandler class. The advantages of the EventHandler are mainly in the fact that the actual calling object is always passed along with the EventHandler. This makes it the ideal choice for static events, and with some quick casting, it’s always easy to get either the specific type or the actual sending object.

My personal preference is that if we’re not passing any data to the subscribing methods, or we don’t need a specific reference (an OnDeath event on the same character as the health component that just triggers a death effect, for example), then a System.Action would suffice. For static events that might be handling a wide range of scenarios (and Hugo has introduced static events quite well in this course!) an EventHandler is the way to go 100%. If you need the ability to assign event responses in the inspector, then a UnityEvent is pretty much the only way to go.