Why events have no return types in .NET?

Question

Events also 'does' something like methods, but they don't have return types and just voids?

I am curious to know, Why is it so? and Why don't they return types?

Answer 1

Because events can be handled by multiple listeners. There is not guaranteed order to the event handlers (though I think they're called in the order they are subscribed in reality.)

Instead, for events that want to "return" some data, the convention is to have a mutable EventArgs object such as CancelEventArgs which can have its Cancel property set to true. The advantage of this over a return value is that event handlers in the chain can look at the property to see if another handler already set it. But you still wind up with a situation where the last one to set the property wins.

If it were a return value, the whole concept would be a lot more complicated.

Answer 2

They don't need to. Think about it. What would they return?

Answer 3

This is because an Event is an asynchronous call. You can have multiple copies of the same event being processed at the same time.

Hence they only pass information as in order to process a return type the event raiser would have to synchronise and wait for the event handler to complete. This would make it just like any other procedure call.

Answer 4

Firing an event is a one-way signal. They are mostly used to achieve loose coupling, because the raiser of the event have no dependency on the consumer. A return value would create a dependency on the consumer.

Answer 5

Actually, events can have return values; simply, it isn't a good idea as it requires more complex processing when there may be multiple listeners... more commonly, there might be a settable property an an EventArgs subclass.

But here's an example of using return values with events; this is not usually a good idea; for information only:

using System;
delegate int SomeBizarreEvent(object sender); // non-standard signature
class Foo {
    public event SomeBizarreEvent Bizarro;    
    public void TestOverall() {
        SomeBizarreEvent handler = Bizarro;
        if (handler != null) {
            Console.WriteLine(handler(this));
        }
    }
    public void TestIndividual() {
        SomeBizarreEvent handler = Bizarro;
        if (handler != null) {
            foreach (SomeBizarreEvent child in handler.GetInvocationList()) {
                Console.WriteLine(child(this));
            }
        }
    }
}
class Program {
    static void Main() {
        Foo foo = new Foo();
        foo.Bizarro += delegate { return 1; };
        foo.Bizarro += delegate { return 5; };
        // writes 5 (the last result wins)
        foo.TestOverall();
        // writes 1, 5
        foo.TestIndividual();
    }
}

Answer 6

It's in the design of event system... The primary purpose of event system is notification not acknowledgment.

Event is a way to notify to it's listeners (observers) that a significant action have occurred. It's not designed in such a way to not only notify the listeners that a significant action have occurred and also acknowledge to event source that it is what???? being handled??? or else... How you decide what to do???

If an event needs to return a value where would it returned it if no handler is associated with it. What if an event have multiple handlers... Then how to decide which handlers value should be returned.

Above all this events can return values. Though it's not a best practice.