Question

Here’s an example:

if (control.InvokeRequired)
{
    control.BeginInvoke(action, control);
}
else
{
    action(control);
}

What if between the condition and the BeginInvoke call the control is disposed, for example?

Another example having to do with events:

var handler = MyEvent;

if (handler != null)
{
    handler.BeginInvoke(null, EventArgs.Empty, null, null);
}

If MyEvent is unsubscribed between the first line and the if statement, the if statement will still be executed. However, is that proper design? What if with the unsubscription also comes the destruction of state necessary for the proper invocation of the event? Not only does this solution have more lines of code (boilerplate), but it’s not as intuitive and can lead to unexpected results on the client’s end.

What say you, SO?

Answer 1

In my opinion, if any of this is an issue, both your thread management and object lifecycle management are reckless and need to be reexamined.

In the first example, the code is not symmetric: BeginInvoke will not wait for action to complete, but the direct call will; this is probably a bug already.

If you expect yet another thread to potentially dispose the control you’re working with, you’ve no choice but to catch the ObjectDisposedException — and it may not be thrown until you’re already inside action, and possibly not on the current thread thanks to BeginInvoke.

It is improper to assume that once you have unsubscribed from an event you will no longer receive notifications on it. It doesn’t even require multiple threads for this to happen — only multiple subscribers. If the first subscriber does something while processing a notification that causes the second subscriber to unsubscribe, the notification currently “in flight” will still go to the second subscriber. You may be able to mitigate this with a guard clause at the top of your event handler routine, but you can’t stop it from happening.