Reputation: 2427
I read about dynamic
and its contributions to the language. The DLR manages any call to a member of an object (dynamic
), to do so it uses reflection mechanisms. But I can't understand the behavior of DyamicObject type (internally).
When you inherit from DynamicObject you get the possibility of creating something like the existing ExpandoObject, you need to overwrite TrySetMember, TryGetMember, and other methods. My question is: when you do object.method, how is this passed to the TryGetMember of our class, at first sight it seems that DynamicObject is bounded to the DLR, but I doubt it.
Upvotes: 0
Views: 332
Reputation: 8850
The answer to the clarified question in comment.
While I'm not sure, I suppose the TryInvokeMember etc functions just wrappers over reflection to overcome the basic design problem of reflection - it throws only one type of exception: TargetInvocationException. All other exceptions including your own exceptions from the methods you are calling are wrapped with TargetInvocationException.
dynamic variables doesn't have that issue - they throw exactly the same excaption that was thrown originally. While they still use reflection internally in some cases, they should unwrap the underlying exceptions. And I thing this is the purpose of TryInvokeMember and related methods. Also it enabled developers of CLR to handle calls of unexisting members in more appropriate and special way.
Upvotes: 1