Should an Event that has no arguments define its own custom EventArgs or simply use System.EventArgs instead?

Question

I have an event that is currently defined with no event arguments. That is, the EventArgs it sends is EventArgs.Empty.

In this case, it is simplest to declare my Event handler as:

EventHandler<System.EventArgs> MyCustomEvent;

I do not plan on adding any event arguments to this event, but it is possible that any code could need to change in the future.

Therefore, I am leaning towards having all my events always create an empty event args type that inheretis from System.EventArgs, even if there are no event args currently needed. Something like this:

public class MyCustomEventArgs : EventArgs
{
}

And then my event definition becomes the following:

EventHandler<MyCustomEventArgs> MyCustomEvent;

So my question is this: is it better to define my own MyCustomEventArgs, even if it does not add anything beyond inheriting from System.EventArgs, so that event arguments could be added in the future more easily? Or is it better to explicitly define my event as returning System.EventArgs, so that it is clearer to the user that there are no extra event args?

I am leaning towards creating custom event arguments for all my events, even if the event arguments are empty. But I was wondering if others thought that making it clearer to the user that the event arguments are empty would be better?

Much thanks in advance,

Mike

Ediva

I'm just getting familiar with event handling also. I just wanted to confirm is EventHandler<object, MyCustomEventArgs> a typo that should be EventHandler<MyCustomEventArgs>? If not, where does this class reside? – Rinse

Yes, good pickup, you are correct, that should read: EventHandler<System.EventArgs>, which I've now corrected. The fact that the sender is an object is implicit when using the EventHandler<> class. For another take on this, you might want to have a look at "Event Signature in .NET — Using a Strong Typed ‘Sender’?" (#1046516), but this alternative approach is non-standard, so you might not want to go this route as a beginner. It is interesting though, and it does work very well. – Ediva

Answer 1

From Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina:

Consider using a subclass of EventArgs as the event argument, unless you are absolutely sure the event will never need to carry any data to then event handling method, in which case you can use the EventArgs type directly.

If you ship an API using EventArgs directly, you will never be able to add any data to be carried with the event without breaking compatibility. If you use a subclass, even if initially completely empty, you will be able to add properties to the subclass when needed.

Personally, I think this comes down to the compatibility issue. If you are making a class library to be consumed by others, then I would use a subclass. If you are only using the events in your own code, then (as Alfred has said), YAGNI applies. It would be a breaking change when you change from EventArgs to your own derived class, but since it would only break your own code it is not too much of a problem.

Supremacy

+1 for you for pointing out external dependencies as a thing to take into consideration. If that's his case HGNI ;) – Georgettageorgette

Yes, this is a class library that will be consumed by others, so I think this is the way to go, and is why I was leaning this way in the first place. I also definitely prefer to follow the design guidelines as much as possible. Thanks, Adrian, for such a complete answer, including the Framework Design Guidelines. – Ediva

Answer 2

YAGNI

I suggest to stick with EventArgs and only use another thing when you really become to need it.

---

UPDATE:

As adrianbanks pointed out, if your code is going to be consumed by other code that is not under your control (i.e. code that you cannot compile yourself) or if recompiling consumer code will be a hassle, then you should use EventHandler<YourEventArgs>.

Georgettageorgette

Thanks for your balanced answer, Alfred. Yes, YAGNI was definitely on my mind when I posted this question. Mostly, I don't like the idea of cluttering up my object model with classes that merely represent System.EventArgs, aka EventArgs.Empty. Overall, though, my class library is consumed by other projects and I am going to go with flexibility and following the Framework Design guiedlines on this one. So I gave Adrian the check mark, but I gave you both a +1 vote. – Ediva