[Opensim-dev] Test before you call OSSL function

[Haravikk]

> On 16 Oct 2019, at 16:45, Kevin Cozens <kevin at ve3syb.ca> wrote:
> 
> On 2019-10-14 11:53 p.m., dz wrote:
>> Why don't you just have the default action of the  " failed " call invoke a
>> standard user defined  error state.
> 
> Interesting idea. One aspect of that is that it should be able to know which state the script was in prior to an error being triggered as it might not be the default one for those scripters who know you can have other states.

As already mentioned, the problem with just returning default values is you can't necessarily test these for an error, as some methods don't return anything at all, while others may return empty lists/strings during normal operation. There's also the possibility of there being scripts that were written in the expectation of failing if a function isn't enabled, so changing the behaviour means they'll suddenly continue when they weren't supposed to, potentially resulting in unexpected/unpredictable behaviour.


I wonder though, what if a function were added so we could control the behaviour?

For example, osslIgnoreDisallowedFunctions(integer ignore), if set to TRUE, all errors due to functions being disallowed would be suppressed, and these functions would then return a default value instead, so your script can continue. The default behaviour (FALSE) would be the current behaviour of shouting an error and failing with no return.

It doesn't solve the problem that you can't really tell if the function failed or just returned a normal empty value, but at least this way the change in behaviour is one specifically requested by the script author, who can take additional steps to handle possible empty returns, either that or they just explicitly don't care and want the errors to go away. Either way this is only a change in behaviour if the scripter asked for it.

This option would also makes it possible to ignore the errors for some functions but not others, by ignoring before the function call, then re-enabling afterwards. It would presumably require a new script property to track this I think?