TargetException thrown while using reflection to add an event handler
Interview Questions practice on Codemia
Over 8,000 real interview questions from top companies, searchable by company and role.
Introduction
TargetException during reflective event subscription usually means the runtime was given the wrong target object or an incompatible delegate binding. Reflection can attach an event handler successfully, but only if the event belongs to the instance you pass and the delegate exactly matches the event’s handler type. The fix is to inspect the event metadata and the target instance rather than treating the exception as mysterious reflection noise.
How Reflection-Based Event Wiring Works
A reflective subscription has five moving parts:
- the type that declares the event
- the
EventInfo - the publisher instance, if the event is not static
- the handler method
- a delegate whose type matches the event signature exactly
Here is a working example:
This succeeds because the event belongs to publisher, while the method belongs to subscriber, and the delegate signature matches EventHandler.
The Most Common Cause of TargetException
The most common mistake is passing the wrong target to AddEventHandler. For an instance event, the first argument must be the object that owns the event.
If the event belongs to Publisher, this is correct:
This is not:
That mistake is enough to trigger TargetException, because the runtime sees an event being attached to an instance that does not actually declare it.
Static Events Are Different
For static events, the target instance should be null.
If you pass a concrete instance for a static event, or null for an instance event, reflection will reject the call.
Match the Delegate Signature Exactly
The handler method must match the event’s delegate type. Reflection does not “almost” bind the method for you.
If the event type is EventHandler<MyArgs>, a plain EventHandler method is not interchangeable. Check eventInfo.EventHandlerType before creating the delegate if you are in doubt.
Validate the Metadata Before Binding
You can fail fast with much clearer errors by validating the reflection results first.
That is much easier to debug than catching a generic TargetException after several reflective steps have already failed.
Common Pitfalls
- Passing the subscriber instance instead of the publisher instance into
AddEventHandler. - Using
nullfor an instance event or a concrete instance for a static event. - Creating a delegate whose method signature does not exactly match the event type.
- Skipping validation of
EventInfo,MethodInfo, andEventHandlerTypebefore binding. - Treating reflection as magical when the runtime is actually enforcing very strict target and signature rules.
Summary
- '
TargetExceptionoften means the wrong target object was passed toAddEventHandler.' - Use the publisher instance for instance events and
nullfor static events. - The delegate must match the event’s handler type exactly.
- Validate reflection metadata before attaching the handler.
- Reflection works reliably here, but only when the event, target, and delegate line up precisely.
Related reading
- Targeting both 32bit and 64bit with Visual Studio in same solution/project
- Tarjan cycle detection help C
- Task based asynchronous operation disabled in PCL Service Reference setting
- Task continuation on UI thread
- Task.async_stream elixir returning strange output
- Task.WaitAll is not waiting - Explanation
- Task Parallel Library - Task.Delay usage
- TaskCompletionSource When to use SetResult versus TrySetResult, etc

OOD Fundamentals
Master object-oriented design from first principles, SOLID, design patterns, and classic interview problems with hands-on coding.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
Interview Questions practice on Codemia
Over 8,000 real interview questions from top companies, searchable by company and role.