event Action vs event EventHandler

Question

Is there any different between declaring event Action lt  gt  and event EventHandler lt  gt    Assuming it doesn t matter what object actually raised an event   for example   public event Action lt bool  int  Blah gt  DiagnosticsEvent    vs  public event EventHandler lt DiagnosticsArgs gt  DiagnosticsEvent   class DiagnosticsArgs   EventArgs       public DiagnosticsArgs bool b  int i  Blah bl                        usage would be almost the same in both cases   obj DiagnosticsEvent    HandleDiagnosticsEvent    There are several things that I don   t like about event EventHandler lt  gt  pattern    Extra type declaration derived from EventArgs Compulsory passing of object source     often no one cares   More code means more code to maintain without any clear advantage   As a result  I prefer event Action lt  gt   However  only if there are too many type arguments in Action lt    then an extra class would be required

User · Answer

On the most part  I d say follow the pattern  I have deviated from it  but very rarely  and for specific reasons  In the case in point  the biggest issue I d have is that I d probably still use an Action lt SomeObjectType gt   allowing me to add extra properties later  and to use the occasional 2-way property  think Handled  or other feedback-events where the subscriber needs to to set a property on the event object   And once you ve started down that line  you might as well use EventHandler lt T gt  for some T

User · Answer

Looking at Standard  NET event patterns we find  The standard signature for a  NET event delegate is  void OnEventRaised object sender  EventArgs args         The argument list contains two arguments  the sender  and the event arguments  The compile time type of sender is System Object  even though you likely know a more derived type that would always be correct  By convention  use object   Below on same page we find an example of the typical event definition which is something like public event EventHandler lt EventArgs gt  EventName   Had we defined class MyClass     public event Action lt MyClass  EventArgs gt  EventName     the handler could have been void OnEventRaised MyClass sender  EventArgs args    where sender has the correct  more derived  type

User · Answer

Based on some of the previous answers  I m going to break my answer down into three areas   First  physical limitations of using Action lt T1  T2  T2     gt  vs using a derived class of EventArgs  There are three  First  if you change the number or types of parameters  every method that subscribes to will have to be changed to conform to the new pattern  If this is a public facing event that 3rd party assemblies will be using  and there is any possiblity that the event args would change  this would be a reason to use a custom class derived from event args for consistencies sake  remember  you COULD still use an Action lt MyCustomClass gt   Second  using Action lt T1  T2  T2     gt  will prevent you from passing feedback BACK to the calling method unless you have a some kind of object  with a Handled property for instance  that is passed along with the Action  Third  you don t get named parameters  so if you re passing 3 bool s an int  two string s  and a DateTime  you have no idea what the meaning of those values are  As a side note  you can still have a  Fire this event safely method while still using Action lt T1  T2  T2     gt     Secondly  consistency implications  If you have a large system you re already working with  it s nearly always better to follow the way the rest of the system is designed unless you have an very good reason not too  If you have publicly facing events that need to be maintained  the ability to substitute derived classes can be important  Keep that in mind   Thirdly  real life practice  I personally find that I tend to create a lot of one off events for things like property changes that I need to interact with  Particularly when doing MVVM with view models that interact with each other  or where the event has a single parameter  Most of the time these events take on the form of public event Action lt  classtype   bool gt   PropertyName Changed  or public event Action SomethingHappened   In these cases  there are two benefits  First  I get a type for the issuing class  If MyClass declares and is the only class firing the event  I get an explicit instance of MyClass to work with in the event handler  Secondly  for simple events such as property change events  the meaning of the parameters is obvious and stated in the name of the event handler and I don t have to create a myriad of classes for these kinds of events

User · Answer

I realize that this question is over 10 years old  but it appears to me that not only has the most obvious answer not been addressed  but that maybe its not really clear from the question a good understanding of what goes on under the covers  In addition  there are other questions about late binding and what that means with regards to delegates and lambdas  more on that later    First to address the 800 lb elephant gorilla in the room  when to choose event vs Action lt T gt  Func lt T gt     Use a lambda to execute one statement or method  Use event when you want more of a pub sub model with multiple statements lambdas functions that will execute  this is a major difference right off the bat   Use a lambda when you want to compile statements functions to expression trees  Use delegates events when you want to participate in more traditional late binding such as used in reflection and COM interop    As an example of an event  lets wire up a simple and  standard  set of events using a small console application as follows   public delegate void FireEvent int num    public delegate void FireNiceEvent object sender  SomeStandardArgs args    public class SomeStandardArgs   EventArgs       public SomeStandardArgs string id                ID   id             public string ID   get  set       class Program       public static event FireEvent OnFireEvent       public static event FireNiceEvent OnFireNiceEvent        static void Main string   args                OnFireEvent    SomeSimpleEvent1          OnFireEvent    SomeSimpleEvent2           OnFireNiceEvent    SomeStandardEvent1          OnFireNiceEvent    SomeStandardEvent2            Console WriteLine  Firing events                 OnFireEvent  Invoke 3           OnFireNiceEvent  Invoke null  new SomeStandardArgs  Fred                Console WriteLine    HeightSensorTypes Keyence IL030    int HeightSensorTypes Keyence IL030             Console ReadLine               private static void SomeSimpleEvent1 int num                Console WriteLine    nameof SomeSimpleEvent1    num               private static void SomeSimpleEvent2 int num                Console WriteLine    nameof SomeSimpleEvent2    num                private static void SomeStandardEvent1 object sender  SomeStandardArgs args                 Console WriteLine    nameof SomeStandardEvent1    args ID               private static void SomeStandardEvent2 object sender  SomeStandardArgs args                Console WriteLine    nameof SomeStandardEvent2    args ID               The output will look as follows     If you did the same with Action lt int gt  or Action lt object  SomeStandardArgs gt   you would only see SomeSimpleEvent2 and SomeStandardEvent2   So whats going on inside of event   If we expand out FireNiceEvent  the compiler is actually generating the following  I have omitted some details with respect to thread synchronization that isn t relevant to this discussion       private EventHandler lt SomeStandardArgs gt   OnFireNiceEvent       public void add OnFireNiceEvent EventHandler lt SomeStandardArgs gt  handler                Delegate Combine  OnFireNiceEvent  handler              public void remove OnFireNiceEvent EventHandler lt SomeStandardArgs gt  handler                Delegate Remove  OnFireNiceEvent  handler              public event EventHandler lt SomeStandardArgs gt  OnFireNiceEvent               add                       add OnFireNiceEvent value                    remove                       remove OnFireNiceEvent value                     The compiler generates a private delegate variable which is not visible to the class namespace in which it is generated  That delegate is what is used for subscription management and late binding participation  and the public facing interface is the familiar    and -  operators we have all come to know and love      You can customize the code for the add remove handlers by changing the scope of the FireNiceEvent delegate to protected  This now allows developers to add custom hooks to the hooks  such as logging or security hooks  This really makes for some very powerful features that now allows for customized accessibility to subscription based on user roles  etc  Can you do that with lambdas   Actually you can by custom compiling expression trees  but that s beyond the scope of this response    To address a couple of points from some of the responses here    There really is no difference in the  brittleness  between changing the args list in Action lt T gt  and changing the properties in a class derived from EventArgs  Either will not only require a compile change  they will both change a public interface and will require versioning  No difference  With respect to which is an industry standard  that depends on where this is being used and why  Action lt T gt  and such is often used in IoC and DI  and event is often used in message routing such as GUI and MQ type frameworks  Note that I said often  not always  Delegates have different lifetimes than lambdas  One also has to be aware of capture    not just with closure  but also with the notion of  look what the cat dragged in   This does affect memory footprint lifetime as well as management a k a  leaks    One more thing  something I referenced earlier    the notion of late binding  You will often see this when using framework like LINQ  regarding when a lambda becomes  live   That is very different than late binding of a delegate  which can happen more than once  i e  the lambda is always there  but binding occurs on demand as often as is needed   as opposed to a lambda  which once it occurs  its done -- the magic is gone  and the method s  property ies  will always bind  Something to keep in mind

User · Answer

The main difference will be that if you use Action lt  gt  your event will not follow the design pattern of virtually any other event in the system  which I would consider a drawback    One upside with the dominating design pattern  apart from the power of sameness  is that you can extend the EventArgs object with new properties without altering the signature of the event  This would still be possible if you used Action lt SomeClassWithProperties gt   but I don t really see the point with not using the regular approach in that case

User · Answer

The advantage of a wordier approach comes when your code is inside a 300 000 line project   Using the action  as you have  there is no way to tell me what bool  int  and Blah are  If your action passed an object that defined the parameters then ok   Using an EventHandler that wanted an EventArgs and if you would complete your DiagnosticsArgs example with getters for the properties that commented their purpose then you application would be more understandable   Also  please comment or fully name the arguments in the DiagnosticsArgs constructor

User · Answer

If you follow the standard event pattern  then you can add an extension method to make the checking of event firing safer easier   i e  the following code adds an extension method called SafeFire   which does the null check  as well as  obviously  copying the event into a separate variable to be safe from the usual null race-condition that can affect events     Although I am in kind of two minds whether you should be using extension methods on null objects      public static class EventFirer       public static void SafeFire lt TEventArgs gt  this EventHandler lt TEventArgs gt  theEvent  object obj  TEventArgs theEventArgs          where TEventArgs   EventArgs               if  theEvent    null              theEvent obj  theEventArgs            class MyEventArgs   EventArgs          Blah  blah  blah       class UseSafeEventFirer       event EventHandler lt MyEventArgs gt  MyEvent       void DemoSafeFire                 MyEvent SafeFire this  new MyEventArgs                static void Main string   args                var x   new UseSafeEventFirer             Console WriteLine  Null             x DemoSafeFire             Console WriteLine             x MyEvent    delegate   Console WriteLine  Hello  World                Console WriteLine  Not null             x DemoSafeFire

[c#] event Action<> vs event EventHandler<>

Examples related to c#