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

Answer 1

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>.

Answer 2

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.