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

Reply via email to