Runtime & concurrency
Reveal answer and reasoning
For the selected synchronous MethodInfo.Invoke overload, an exception thrown inside the target method is wrapped in TargetInvocationException, with the original failure available through InnerException. The same method invoked through a directly typed delegate exposes its target exception without that reflection wrapper. This explains an invocation boundary, not a rule that every reflection-related error has the same outer type.
Selection, argument binding, and invalid target errors can occur before the method body runs. A returned Task can also fault later when awaited rather than during Invoke. A common wrong answer catches any exception and calls it expected input validation, accidentally accepting an ambiguous lookup or wrong argument shape. A dispatcher should preserve those categories and enough member identity for diagnosis.
Avoid asserting localized messages or casually rethrowing only an inner exception in a way that discards useful failure context.
What a strong answer covers
- The selected Invoke path wraps synchronous target failures.
- Binding/setup errors are a separate category.
- Returned asynchronous failures have another boundary.
Common pitfall
Treating every reflection failure as the same wrapped domain exception.
Follow-up questions
- How would a faulted returned Task be observed?
- What advantage can a typed delegate provide after discovery?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.