Using reflections – Intrinsic functions

Continue reading

As you may have already noticed, there is nothing more annoying than a well hidden run time error in the code that you have written.

Imagine a simple scenario where you want to prompt the user with the name of the method in the table or name of the table itself (generally in practice you would rarely do that, but for the sake of simplicity lets say you do), you would probably do something like this

‍print "MyTableMethod";

What is wrong with this approach is that when for some reasons, you change the name of the table method you will have to remember to change it here as well, and believe me you will forget about that eventually. Here is not a big problem, the user will be just prompted with the wrong table method name, but what if another part of our program refers to this method and tries to call it using, for example, dictionary API like here


With this approach you will be doomed to suffer from run time errors, but fortunately there is a way to mitigate this by using so called intrinsic functions, like this

dictTable.callObject(tableMethodStr(MyTable, MyTableMethod)));


dictTable.callStatic(tableStaticMethodStr(MyTable, MyTableMethod)));

if it is a static method.

When you do it like this you moved the issue from the run time to the compiler, so every time that you change table name or method name compiler will warn you that there is an error and it should be corrected.

You have corresponding intrinsic function for all elements in AOT, so you can reference them by name. All intrinsic functions beside identifierStr provide you with compile checking, however it is still better to use identifierStr than literals if for example none of the other intrinsic functions are available.

For more information about intrinsic functions please refer to the following link:

Subscribe to our newsletter

Get Dynamics 365 news and insights

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.