Perhaps you mean an on_error() event instead of a state change? An unexpected state change can be difficult to recover from (closing listeners. timers, and whatnot, and not knowing which state was active before the change occurred).
On Wed, Oct 16, 2019 at 5:55 PM dz <d...@bitzend.net> wrote: > You miss the point... > > LSL programs function in States... most folks only ever see the > DEFAULT state label and ignore it, > What I am suggesting is that the new LSL programs Include a ONERR > State that would be invoked in the event of a OSSL call failure > This allows the LSL program to decide if it is a fatal error and ( > maybe ) OwnerSay the returned value, or (maybe) ignore it and > return to the Default state with the call disabled. > > Obviously there needs to be a "default" ONERR state defined for > programs that do not explicitly define one... > > But the error handling required in the script engine is trivial, trigger > the ONERR state in the calling program ( and maybe pass a code/string) > No additional lsl functions are required you just push ONERR into the > State and call the Change State function that exists > > This approach has the advantage that it will also work for scripts that > do NOT call OSSL functions, but that may otherwise Fail for Unknown > reasons.. > > On Wed, Oct 16, 2019 at 10:43 AM Haravikk <open...@haravikk.me> wrote: > > > > > > > > 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. > > > > ... > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@opensimulator.org > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list Opensim-dev@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
