• 25Mar

    The problem: runtime error handling in LSL is… well, it’s practically nonexistant. If something goes wrong, the script will usually shout some message to the world and then die. The obvious problem there is that you have to then manually restart the script and lose all data! Also, for the security-concious, it can potentially reveal implementation details of your script.

    Idea: a new event in LSL, error, which would allow scripts to intercept and deal with error messages in a sane and consistent manner. Here’s an example:

            integer a = 1/0;
        error( integer type, string message )
            if( type == ERROR_MATH )
                llOwnerSay( message + "You should have paid more attention in math class." );

    The two parameters for the error event are the type, which is one of a selection of integer constants, and the message, which is a human-readable message describing what went wrong. In this case, the type is ERROR_MATH (indicating a math error), and the message would be something like “Error: Division by zero.”. The output from this script would be a message to the owner, “Error: Division by zero. You should have paid more attention in math class.”

    Some more useful (and less insulting) ways of handling errors might be to reset the script, send an IM to an assistant shopkeep, clearing some buffers to free up memory, giving a custom message on chat, or some other appropriate behavior for that particular application. If the script doesn’t define the event block, errors are reported in the default way, as they are now (e.g. shouting the error on the debug channel).

    To complement the new error event, would be a new function for triggering errors: llError( integer type, string message ). When called, it triggers an error of the given type, using the given message. If an error event block is defined, the error is given to that block to be handled; if there’s no block, it’s handled in the default manner for that event type.

    A second new function would be llNoHandleError, which behaves like llError, except that it always performs the default handling, bypassing the error event block if it exists. This could also be used within the error event block to “pass through” event types that it’s not intended to handle.

    So, scripters: give me some feedback on this. Should we make a JIRA for this, or is it actually a really stupid idea?

    Posted by Jacek Antonelli @ 8:01 pm


4 Responses

  • Mike Gunderloy Says:

    It’s a nice idea, and would certainly make writing decent scripts easier. But whether I’d want a JIRA for it depends on how Linden Lab is organizing its internal coding effort around scripting. If we really are going to go from LSL-on-Mono to Other-Languages-on-Mono, then I’d hate to see much effort go into adding new features to LSL; it’s so far behind the various .NET languages that I’ll drop it like a hot rock as soon as we can work in any of those other languages.

  • Nacon Says:

    Not possible because the script is a runtime event of itself. Once it ran into an error, it cancels and abort the script on the spot. Therefore, the Error event won’t get triggered.

    It’s possible to have a script feed its error data to another script but that’s not an ideal way to go. I’d suggest take-a-step-back statement to work in different path.

  • Nacon Says:

    (augh… my post got cut off)

    Something like this…

    float G = 4;
    float T = 0;

    iferror( (G / T) == MATH_ERROR)
    { T = 0.1; }

    if( (G / T) == (G * 10) )
    { llSay(0,” You have 40 bucks”); }

    { llSay(0,”I have no idea how much you have…”); }

  • Takuan Daikon Says:

    We should definitely have a JIRA for this!!! This would be so helpful in assisting to find the location of problems that I am currently seeing due to server-side changes causing errors in my scripts where no errors have existed for over a year.

    If you’ve not already created a JIRA, will you please? And give us a linky?