> On 16 Oct 2019, at 16:45, Kevin Cozens <ke...@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?
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
