Why do event handlers always have a return type of void?

Hey, I wondered why is it that the return type of events such as

private void button1_Click(object sender, EventArgs e)

is always 开发者_Go百科void?

Can it return any other value too?

An event handler signature, that is the return type and the number and types of arguments it takes, are determined by the signature of the delegate used to define the event. So the Click event of the Button in your example does not support any return values.

Typically you would not expect to return a value from an event handler as a function return value because an event can have multiple subscribers and each would be returning a return value independently of the other handlers and would require special event firing code to decide what to do with all the return values.

Typically, if you need to communicate back from an event handler the EventArgs structure would contain members that the handler can update and each handler will get an opportunity to look at the values and update accordingly, and the code firing the event only needs to react to the final value in the structure.

An event can have a return value. But it is a BCL guideline to return void (and to have 2 parameters).

Returning a value becomes a bit confusing when you use the multicast property of events. The returned value is the value of the last handler executed. The return of all other subscribed handlers is lost, and because events are used for decoupling, you don't have much control over the order in which they are executed. This makes a return value very impractical.

It is another BCL practice to share and return information through a writable property of an EventArgs descendant, for example the Cancel property of the Window.Closing event. All handlers can see and change this. Still a last-one-wins solution, but better.

But having said all that, you could still write:

delegate int Summer(int[] arr);  // delegate

class Program
{
    public event Summer OnSum;   // event

    void DoSum()
    {
        int[] data = {1, 2, 3} ;              
        int sum = 0;

        if (OnSum != null)  
          sum = OnSum(data);   // execute it.
    }
}

Aside from the fact that .NET expects a certain signature for the events in standard controls, consider this: an event can have multiple event handlers attached, which one of the return values would be used?

It just doesn't make sense for event handlers to return a value. Typically, they will modify the state of some object that derives from EventArgs to communicate something back to whatever fired the event.

In c#, Events could be of two types

1. Multicast
2. UnitCast

Multicast event are those who has more than one subscriber. when a multicast event is raised, then multiple handler would be invoked because you have subscribed more than one event handler. So, multicast event are intended to be used for calling multiple handler and multicast handler can't have return type why??

because if multicast delegate has return type, then every event handler would return some value and return value of one event handler would be replaced by the next event handler value.

suppose you have a multicast delegate as following

public delegate int buttonClick;

public event buttonClick onClick;

onClick += method1
onclick += method2
onclick += metho3

when this event would be raised then value returned by method1 will be replaced by value return by method2 and eventually value of only method3 would be received.

Therefore, in case of Multicast delegate, it is always recommend not to return any value.

but in case of unicast deleagte wherein you would have only one subscriber. So you can return value for fulfilling your purpose

So, for multicast delegate - No return type and for unicast delegate - can have return type

Multicast delegate can also return multiple values but for that event has to be raised manually.

Event in case you opt that multicast delegate should also return values, lets say I am having an event which is bind to 4 event handler and it takes two integers and one handler does add, second subtraction and third multiply and last divide. So, if you want to get the return type of all the handlers, then you have to raise the event manually in the following manner,

var handler = _eventToRaised.GetInvocationList();
foreach(var handler in handlers)
{
  if(handler != null)
   {
    var returnValue = handler()// pass the values which delegate expects.
   }

}

You can't do this because the delegate that handles the event is expecting a certain signature (you'll get compile error if you try and change it). For example the delegate in this case (Button.Click) is a System.EventHandler, it has to match that signature to compile/function as a delegate at all:

public delegate void EventHandler(Object sender, EventArgs e)

This is just how delegates work, when you look at how it's usually used, it makes more sense:

MyButton.Click += button1_Click;

If you returned anything else...what would it be used for? If you intend to call something that returns a result...that's what a method is for, not an EventHandler :)

For sure, events can return values.

   [TestClass]
   public class UnitTest1 {
      delegate int EventWithReturnValue();

      class A {
         public event EventWithReturnValue SomeEvent;
         public int LastEventResult { get; set; }

         public void RaiseEvent() {
            LastEventResult = SomeEvent();
         }
      }

      [TestMethod]
      public void TestMethod1() {
         A a = new A();
         a.SomeEvent += new EventWithReturnValue(a_SomeEvent);
         a.RaiseEvent();
         Assert.AreEqual(123, a.LastEventResult);
      }

      int a_SomeEvent() {
         return 123;
      }
   }

However, it's not very common to use events return value to exchange information between components and their consumers.

the default EventHandler delegate defined this signature. However, you are free to create your own events with your own return types if you wish.

public class AnEvent
{
  public delegate MyReturnType MyDelegateName();
  public event MyDelegateName MyEvent;

  public void DoStuff()
  {
    MyReturnType result = null;
    if (MyEvent != null)
      result = MyEvent();
    Console.WriteLine("the event was fired");
    if (result != null)
      Console.Writeline("the result is" + result.ToString());
  }
}

public class EventListener
{
  public EventListener()
  {
    var anEvent = new AnEvent();
    anEvent.MyEvent += SomeMethod;
  }

  public MyReturnType SomeMethod()
  {
    Console.Writeline("the event was handled!");
    return new MyReturnType;
  }
}

As a number of people have already stated this a convention not a constraint. You can have an event return things within the EventArgs itself. Microsoft uses this pattern in many places, see the FormClosing event in WinForms. So if you want to return a value do something like the following:

public class AllowCloseEventArgs : EventArgs
{
    public bool AllowClose = true;
}

public void AllowClose(object sender, AllowCloseEventArgs e)
{ e.AllowClose = false; }

Knowing this now let's discuss why the designers chose the 'standard' void-return prototype of events:

1. If they had a return value what type would it be?
2. If the event returned a value, what would that value mean?
3. By not having a return type, events can be one-directional. Meaning if I don't care about exceptions I can 'fire and forget' the event like calling Control.BeginInvoke(...)

Update: Ben rightfully adds: #4: what if an event needed to return more than one value?

The return type is void because it's a sub routine, not a function. You could have it return a value, but event handlers (which is what a sub routine hooked to a button click event is) aren't exactly intended to.

In VB, this line of code would be:

Private Sub button_Click(ByVal sender As Object, ByVal e As EventArgs)

The explicit "Sub" statement in VB makes a little more sense in this case, but remember, all voids in C# are just subroutines ... they do something in the code based on arguments but don't return a value. They can, however, change the values of the arguments passed in.

As a college professor of mine used to say about almost every question "It depends on the implementation". In this particular case, working with event handlers, there is nothing implicit with this model that would prevent and implementation of this pattern to return something back to the calling code. However, you're passed both the sender object as well as the originating event arguments, with basically form your executing environment context, there is no need to return anything since you can work directly with those references to achieve any relevant functionality.

Other frameworks may allow for an event handler to return something.

introductory note: If the [single] method you want to call is on the same or lower dependency level as your calling code, then you can just go ahead and call it, there will be no need for events. So; events are only useful when at least one of your event raises (calls) is going to call a method from a layer above.

Now, long answer depends on whether you write your own delegate and marking it as an event (1) or use EventHandler (2):

1. If writing your own delegate, you could just have return the result you need. The problem though is that with multicast delegates only the result of the final subscribed method is returned.

    public class TestEvents
    {
        public event SomethingHappenedHandler1 SomethingHappened1;
        public event EventHandler SomethingHappened2;
    
        public void Run()
        {
            SomethingHappened1 += Scenario_DelegateOnly.SubscriberMethod;
            SomethingHappened1(this, 13, 15);
    
            SomethingHappened2 += Scenario_EventHandlerAndEventArgs.SubscriberMethod;
            SomethingHappened2(this, new MyEventArgs2(33, 35));
        }
    }
    
    //1
    public delegate int SomethingHappenedHandler1(object sender, int arg1, int arg2);
    public static class Scenario_DelegateCanHaveReturnValue
    {
        public static int SubscriberMethod(object sender, int arg1, int arg2)
        {
            Console.WriteLine($"{sender.ToString()} {arg1} {arg2} ... returning {arg1} * {arg2}");
            return arg1 * arg2;
        }
    }
    
    //2
    public static class Scenario_EventHandlerAndEventArgs
    {
        public static void SubscriberMethod(object sender, MyEventArgs2 args)
        {
            Console.WriteLine($"{sender.ToString()} {args.arg1} {args.arg2}");
        }
    }
    public class MyEventArgs2 : EventArgs
    {
        public MyEventArgs2(int arg1, int arg2)
        {
            this.arg1 = arg1;
            this.arg2 = arg2;
        }
        public int arg1;
        public int arg2;
    }

2. If using EventHandler signature of your method return type will always be "void". Most often event raises are fire and forget operations (such as button_Click) and we might not care about results of operation, but when we do need some feedback, there is always a workaround because subscriber method can save those results to a property on the publisher; it just has to cast "sender" object to get an instance of publisher [which should be no problem unless subscriber is below the publisher in dependency (scenario noted where we did not need events to begin with!)].