Senior · Design · Reflection invocation and exception boundaries

Design failure reporting for a reflection dispatcher that can return either values or Tasks.

Think through your answer before opening the explanation.

Runtime & concurrency

Reveal answer and reasoning

Separate member selection and signature validation from invocation, then distinguish synchronous target failure from a returned asynchronous operation's completion. Retain and await an owned Task before reporting its final outcome. Keep a stable application-level error contract while preserving diagnostic method identity and the actual exception boundary internally. Do not translate every setup defect into an ordinary domain rejection simply because the dispatcher has a broad catch available.

Test a valid value, a domain exception, an unsupported signature or argument, a successfully returned but faulted Task, and cancellation with a defined owner. A directly created typed delegate can simplify repeated calls once discovery is validated, but it does not remove target failures. The wrong design assumes Invoke observed an asynchronous method's eventual success when it only returned its Task, or assumes any exception seen near reflection must be a TargetInvocationException that can safely be unwrapped without further classification.

What a strong answer covers

  • Selection, invocation, and async completion are distinct.
  • Await every owned asynchronous return.
  • Preserve useful diagnostics behind stable application results.

Common pitfall

Reporting success when reflection merely returned an unobserved asynchronous operation.

Follow-up questions

  1. How would a ValueTask return change ownership handling?
  2. What would you log without exposing internal stack details to a client?

Self-review

Choose what to revisit. These marks are your own assessment and are separate from lesson completion.

Primary references

Open lesson and code ↗

← All interview questions