While I agree that the on-error (event) might be the more elegant
solution, it suffers the downside of requiring significant additional
coding in the LSL script.
It is true that state changes are disruptive, but we are comparing it to a
solution ( NOW) where the program fails and spams everyone in the region.
My expectation is that a very large portion of the scripts using OSSL
functions wouldn't be very useful if the OSSL function is not permitted,
so failure is a valid result.
Scripts designed to fail in a limited way can put the call to the
function in a "SETUP' state which would allow them to easily set a "do
the OSSL call" flag (TRUE/FALSE) and restart initialization.
retrofitting scripts with generic [example] bit of code for the onErr
state is relatively simple cut and paste..
state OnErr
{
state_entry()
{
llOwnerSay( "OSSL call failure");
}
}
This simple code block can also be easily "stubbed out" as a default
action in the script engine for processes that do NOT include the state
definition as written.
Trying to design a default event handler that adds this functionality
seemed to me like it might be too contentious and hard to get agreement on.
I agree... this isn't the best solution.. But is is SIMPLE, works for
ALL scripts, and is an opportunity to get a LSL code example out
demonstrating the proper use of script states,
I think it is certainly more elegant that adding an additional
function call that is required BEFORE EVERY OSSL function.
It is certainly less likely to create as many problems as requiring 2
function calls and/or modifying the script engine to support try/catch
blocks..
If you REALLY HAVE TO muck with the script engine... why don't you
give us $INCLUDE. then the retrofit for existing scripts can be
"$INCLUDE ErrState.lsl" .....
On Thu, Oct 17, 2019 at 1:37 AM Dahlia Trimble <dahliatrim...@gmail.com>
wrote:
> 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
>
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
