Is Delegate.EndInvoke() really necessary?

I've read a couple of forums and even a stackoverflow question or two saying that Delegate.EndInvoke is necessary when using Delegate.BeginInvoke. Many of the articles I've read talking about using BeginInvoke have failed to mention using EndInvoke. Also I've deployed production code using only BeginInvoke and there doesn't appear to be any memory issues. The way I've used BeginInvoke is generally with threads that I don't care about when they finish or how long they take to process.

Solution 1:

From the MSDN article 'Calling Synchronous Methods Asynchronously':

No matter which technique you use, always call EndInvoke to complete your asynchronous call.

Now, there is theory and then there is practice. You have found, like many other developers before you, that you can often get away with ignoring this documented requirement. It may be an implementation detail whether EndInvoke actually does anything that's absolutely necessary to prevent your application from crashing, leaking memory, etc. But here's the thing: if it's a documented requirement, you really ought to do it. This is not just about theory; it's about protecting yourself in the event of change.

By documenting this requirement, the designers of this asynchronous calling mechanism basically gave themselves the freedom to change the way BeginInvoke and EndInvoke work down the line so that, if there were sufficient reason (e.g., a performance enhancement), EndInvoke could suddenly become a lot more necessary. Suppose it would suddenly result in a deadlock if you forgot it. They've already covered themselves by saying always call EndInvoke; if your app stops working because you didn't follow this requirement, the onus is on you.

I'm not saying this is necessarily a likely scenario. My point is simply that you shouldn't—or at least I wouldn't—ask "Is this really necessary?" with the mindset of If I can get away with leaving it out, then I will, since it is documented that you should do it.

Solution 2:

It is absolutely necessary if you plan on throwing exceptions from your thread and expect to catch them properly. If you do not call EndInvoke, the thread that throws the exception will vanish and you won't know anything about it.

To support EndInvoke, provide an AsyncCallback, and in that callback method, be sure to wrap your call to EndInvoke with a try/catch block.

While you could get away with not doing it if you don't care about what happens in the thread, I would argue that it's a very good habit to get into to just call EndInvoke. You never know, a junior developer could some day get in there and change the code in your thread, and throw an exception. Then the updated app gets deployed, and the service calls start coming in.