C# – Should the sender of an event always be a generic Object

cevent

When programming events in C#, it is advised to create a delegate in form of:

delegate XEventHandler(object sender, XEventArgs e);

My question is on the first argument of the delegate, object sender. Does it always have to be a generic object? Having a sender of type object always results in code similar to this.

val = ((ConcreteType)sender).Property;

or, even more verbose,

ConcreteType obj = sender as ConcreteType
if (obj != null) { ... }

One argument against strongly typed senders is that other objects can forward the event without worrying about the type. While this might make sense in GUI environments, I am not sure if it could benefit outside a GUI.

What if the class of the sender is always known (at least as an abstract class)? For example, if I am implementing a ListChanged event in an abstract List class, and if other classes are going to inherit it (e.g. LinkedList, ArrayList), is it all right to define my delegate with a sender of type List?

delegate ListChangedEventHander(List sender, ListChangedEventArgs e);

Or, would there be a downside of changing the conventional object sender to a more specific type?

Best Answer

At this point, it is mostly a (pretty strong) convention. That is, it will be weird if you write a library that does not follow that convention.

The Event Design Guidelines say:

DO use object as the type of the first parameter of the event handler, and call it sender.

However, you may note that current guidance says that you should not define your own custom delegate for events, but use EventHandler<T> instead, if you can.

As for the design, I would guess that it also promotes the reuse of event handlers, even in contexts not originally foreseen by the original designer of the event.

Related Solutions

C# – Web API architecture design

You are overcomplicating this.

Web API is designed to let you write your controller code is as "natural" a way as possible. The IHttpActionResult return type is mostly intended as an escape hatch when you want maximal flexibility.

Here is how I would write your method:

public ClrObject1 Method1(string arg1 = null, string arg2 = null, string arg3 = null)
{
    ClrObject1 varClrObject = (from p in db.clrObject1
                               where p.column1 == arg1
                               select p).SingleOrDefault();

    if (varClrObject == null)
    {
        // This line will automatically return a 404 error to the user.
        throw new HttpResponseException(HttpStatusCode.NotFound);
        // If you want, you can also build a full HttpResponseMessage
        // to give more details about the error.
    }

    // Web API will automatically return serialize and return your object
    // in a 200 OK response.
    return varClrObject;
}

You will notice that I do not put a try-catch block to handle exceptions - the reason is that, if any exception is raised and unhandled, an error 500 will be returned to the user, which is usually what I want. Also, you do not want always to return details about your exception in the HTTP response, as such information could disclose information that could be used in helping hacking the application server.

API Design – Should Event Listeners Be Held in Weak References?

Why shouldn't event listeners outlive the object that registered them? It seems like you are assuming event listeners should registered by methods of controls(if we take the GUI example) - or more precisely, methods by objects of classes that inherit the GUI toolkit's controls. That's not a necessity - you could, for example, use a specialized object for registering event listeners and ditch that object afterwards.

Also, if event listeners were weakly referred, you would have to actually keep references to them even if you never use that reference. Failing to do so will make the listener be collected at a random time. So, we get a bug that is

Easy to create by mistake(all you have to do is to forget storing an object in a reference variable that you'll never use).
Hard to notice(you'll only get that bug if the GC collect that object).
Hard to debug(in the debug session - which always works like a release session - you'll only encounter that bug if the GC collected the object).

And if avoiding that bug is not good enough incentive, here are some more:

You'll have to think of a name for each listener you create.
Some languages use static anlysis that'll generate a warning if you have a private member field that's never get written or never get read. You'll have to use have a mechanism for overriding that.
The event listener does something, and once the object that has it's strong reference is collected it'll stop doing that something. You now have something that affects the program's state and depends on the GC - which means the GC affects the concrete state of the program. And this is BAD!
Handling weak references is slower, since you have another level of indirection and since you need to check if the reference was collected. This wouldn't be a problem if having event listeners in weak references was necessary - but it isn't!

Best Answer

Related Solutions

C# – Web API architecture design

API Design – Should Event Listeners Be Held in Weak References?

Related Topic