Question about CallSecureProtected

[SSM24]

I was looking at the API page and I noticed it says this:

To call a protected function, you must use the following code : if IsProtectedFunction("TheNameOfYourFunction") then     CallSecureProtected("TheNameOfYourFunction", arg1, arg2, arg3) else     TheNameOfYourFunction(arg1, arg2, arg3) end

However in the past I've simply just used CallSecureProtected without checking IsProtectedFunction first (specifically when I used RequestMoveItem in Restock Bank Materials) and I haven't run into issues or had any reported. But it says on the API page you "must" use that first form, in bold and everything. Out of curiosity, what exactly is the benefit of doing so? Is it just for forward compatibility in case they un-protect an API function in the future, or is there another reason?

[sirinsidiator]

I remember asking ZOS that same question a long time ago and they where as surprised to see this code as you are.
The only reason we could think of is that whoever originally wrote it was using one of the game launchers that allowed to circumvent the security system of the api (which is obviously against the TOS) to call protected and private functions just as normal functions from addon code and everyone else just copied it without understanding it.
Guess nobody bothered updating the wiki afterwards.

[Baertram]

I remember (several years ago though) that calling a secure function directly, without using CallSecureProtected(funcName, ...), was raising lua errors?

[sirinsidiator]

Originally Posted by Baertram I remember (several years ago though) that calling a secure function directly, without using CallSecureProtected(funcName, ...), was raising lua errors?

It does. The point is, you don't need to warp it in the "if IsProtectedFunction", since that would always be true, unless you use a hacked game client.

[ZOS_DanBatson]

If you call a function with CallSecureProtected and the function is not a protected function, then it will fail. You don't specifically have to check if it's protected if you already know from the documentation that it's protected, although if you just assume it is and we change it later to no longer be protected your code will suddenly break if you're not checking first. So, you know, caveat emptor. CallSecureProtected returns a bool telling you if it worked, and if it didn't, it returns a string explaining what what wrong.

Also just as a reminder, protected just means you can't call it during combat. Private means you can't call it at all.

[SSM24]

Originally Posted by ZOS_DanBatson If you call a function with CallSecureProtected and the function is not a protected function, then it will fail. You don't specifically have to check if it's protected if you already know from the documentation that it's protected, although if you just assume it is and we change it later to no longer be protected your code will suddenly break if you're not checking first. So, you know, caveat emptor. CallSecureProtected returns a bool telling you if it worked, and if it didn't, it returns a string explaining what what wrong. Also just as a reminder, protected just means you can't call it during combat. Private means you can't call it at all.

So essentially I was correct then, the only real benefit of doing it this way is potential forward compatibility. It sounds like this would also apply equally to unprotected functions if they become protected in the future, at which point stuff would break anyway (and probably in an even more widespread way), so probably not worth worrying too much about. Thanks!

[Baertram]

Thanks for the explanation Dan, updated the Wiki too.