Better Script Error Handling And Reporting!!

One of the things that irks me *alot* is being confused when I get a runtime error on a script in a prim with many other running scripts.

We scripters need a more proper way of getting errors that our scripts run into.

I propose:

1. That errors are IM'med to the owner of the object.
   
2. That errors contain:
   1. The Sim Name
      
   2. The Object Name
      
   3. The Script Name
      
   4. The Line Number Error Occured
      [/list=1]
      
   
   This is totally possible! We have script functions that can do all of this (save the last one) already!
   
   Since scripts are compiled, perhaps the last one can be instead the function (state_entry(), foo(), collision()) and state where the error occured.
   
   Now, who's with me!!
   
   ==Chris

Agreed.

I endorse this product and/or service.

Agreed here too.

Agreed *if* it's easy to implement. Otherwise, script and object lockdown for one's land, and Debug lockdown for one's land are priority number one for me followed closely behind by direct object-to-object comms and write to notecard (preferably non-delaying).

We cant have everything all at once

To some extent I'm inclined to think: leave LSL as it is right now, add the functionality to the game that we need, then rather than just tweak LSL here and there, rewrite it to be Python-esque and really easy to use, like in 2 years time, when SL is really big.

Azelda

Boooo couldn't disagree with you more Azelda.

Don't mind too terribly a change in language you suggest.

However the scripting language is the same as it was essentially when I started beta over a year ago. There have been a few added functions here and there - vehicles and particles are nice, some land tools and a couple extra string manipulators - but overall it is unchanged.

What SL is already great at is building, art, land, socializing. The functionality it needs is better scripting. The world needs to be interactive, the world needs to be a game platform. And for this many things are needed. I don't think I will derail this thread further with things the script language needs. This thread is about errors.

While I support the concept of this thread I think it stops short and takes a wrong turn. What we really need is true error handling. With the event driven system the implementation is obvious - an error (integer type, string mes) event. When you have an error, before the script dies the error event is called with the needed data. If it can be corrected it is. Even requireing a llCatchErrors(integer type) would be more than fine.

Also llGetFreeMemory() needs to be fixed, it currently counts free memory as Total Memory - (Stack + Heap). While that sounds correct, in the same memory space is the byte code of your script which means what it should be is Total Memory - (Stack + Heap + Bytecode).

> What SL is already great at is building, art, land, socializing. The functionality it needs is better scripting. The world needs to be interactive, the world needs to be a game platform.

Heh! It's funny, I'm sure I posted exactly the same thing somewhere!!!

I guess my thinking is that tinkering with LSL as it is will never make it into an easy-to-learn language because that is not what C is/was designed for.

My fear is that if we tinker with LSL as it is without fully restructuring it into a more intuitive language, such as Python or - I know you hate it - vbscript - we are pouring effort into something that will ultimately not meet the requirements, and that effort could be better spent on functionality that is really critical to the game.

By the way, sortof relevant to this thread, there are some things that LSL does really well. One observation is that there are hardly ever any runtime errors. They are all caught at compile time or by bounds checking. They're not something that makes me go aarrrggghhhh, I cant build a game yet because...

Azelda

Actually I think this thread is about run time errors and their poor handling. I have dealt with many, many obscure run time errors. Games that will run flawlessly for literally thousands of times then get a stack heap (yay mem leak, at least its slow). Last time I was able to log in I was looking at all my games having bounds check errors when played, an error by the way which I had never seen before. Weeeee. I also have seen a weird bug where a black jack table that uses switching of textures will actually cause a client to crash to desktop. It doesn't trigger an error and isn't 'repeatable' - at least that I am able to determine.

I personaly like the C like format, while it isn't exactly easy to learn for new people, it is slightly less complicated than C appears, which could cause someone to learn LSL which in turn would help them move on to C if they like because they're more used to the set up etc.

I don't have a problem with run time errors really, they give you the line and the place where they occoured, more description would be welcomed of course. The main errors I have problem with is the "stack heap" and the like, the ones that just make you go "Huh?!" when you first see them and then you have to come here to hopefully find an answer.

Only compiler errors give this information, run time errors do not.

Gah. Please dont go off topic
I personally do not like python or perl. I favor strongly-typed bytecode-compiled languages over interpreted, weakly-typed languages. Of course, LSL would be better if it was Object-Oriented, but atm I think the syntax, stucture and everything else is pretty decent, just lacking in more robust functionality.

I agree with Ama in that we need a full-fledged error catching implimentation, but I was thinking more of a baby-step toward that, and instead, something that would be relatively easy to impliment (at least IMO).

==Chris

These are compiler errors



These are runtime errors

==Chris

Call me lazy, hell I'll call me lazy, but despite LSL coding practices including very liberal use of
if (debug & LEVEL) llWhisper(...);

I have found enough run time errors in old code running on 1.2 with *totally bounded and small* storage needs that I have effectively given up scripting for the nonce.

N.B. This is not an "SL sucks" post or even an "LSL sucks post" it is just that LSL work feels too much like work at present or *gasp* batch job submission (could I really be that old?)

Sorry about my confusion about which errors are what, thank you for the corrections

> it is just that LSL work feels too much like work at present or *gasp* batch job submission (could I really be that old?)

Yes, it does doesn't it.

Azelda

Agreed, what would even be better for me right now is the description of a 'math-error' I have a script that does not have any division but gives a math error (rarely)...
anyone know other functions that can give a math error?

Hehe, shoulda posted this one in the Scripts and Scripting forum, under my topic on obscure runtime error discriptions.

Math errors can be caused by:

Division by 0,
llPow() being too big,
llSqrt() with a negative or 0 argument,
wierd vector/rotation math.

Well... what math are you actually doing in your script Mark?

llAsin and llAcos with arguments > 1.0 or < -1.0

Error catching is becoming essential more and more as our scripts become more complex. We're hitting a growth wall here, which along with other limitations (ie memory size), will prevent or significantly slow implementation of some really remarkable concepts.

i second this idea. add an 'error' like 'default' , that the script enters. upon entering this state, error information logged from the error is reported properly (i.e. to the owner), and the object stays within the error state until reset.

proper reporting, and proper error state managment is essential i feel.

ry->catch may not be a good implemntation in LSL, given the minimal memory allocations, so just fix the reporting

> Agreed, what would even be better for me right now is the description > of a 'math-error' I have a script that does not have any division but > gives a math error (rarely)...
> anyone know other functions that can give a math error?

Oooo, I have this error now too. The only things in my script that look like candidates are:
- llRotBetween
- llVecNorm (because it's implicitly dividing by VecMag)
- something to do with lists (maybe an off-by-one error?)

You're right. It's pretty annoying to troubleshoot. If we had writetonotecard we could at least make a debug file.

I'll add to the list of people who want to at least know the line number where a runtime error occured

Azelda

Well, just for info, my maths error is caused by the following command:

rotation test = llRotBetween( <1,0,0>, <-1,0.00011,0.00000> );

(And the workaround for normalized vectors is:

rotation RotBetween( vector normvectorone, vector normvectortwo )
{
    if(((integer)( normvectorone * normvectortwo * 100 ) ) != -100 )
    {
        return llRotBetween( normvectorone, normvectortwo );
    }
    else
    {
        return llAxisAngle2Rot( <0,0,1>, PI );
    }
}

)

does the following still cause the error?

rotation test = llRotBetween( <1,0,0>, <-1.0,0.00011,0.00000> );

Opinion: the vast majority of the time LSL handles runtime errors in a method which works really well for SL: it just ignores them and substitutes a bounds value.

Example:

llSetText( "test", <10, 0, 0>, 1.0 );

Colors are floats with axes between 0 and 1, so using 10 is illegal. The way LSL treats this is to just truncate it to the nearest bound, which is 1.0.

When LSL doesnt do this, it's basically a bug (eg llGetRotBetween, I'm sure that wasn't the intended behavior, and I've bug reported it).

For ACos and ASin, it could be useful to simply apply the same principle, and just make them return 0 (or a suitable default) if you give it a bad value. It's not really great but it's good enough for most circumstances, and it turns what would be runtime errors/crashes into logical errors.

For the Bounds Checking errors that have been reported recently, IMHO this is a bug in LSL, and will get fixed soon.

Azelda

> does the following still cause the error?
>
> rotation test = llRotBetween( <1,0,0>, <-1.0,0.00011,0.00000> );


Yeah, the problem is basically caused by trying to get the rotation between two opposite directions, and the algo cant work out which axis to rotate around.

For example, to get from <1,0,0> to <-1,0,0> you can either rotate about the z axis, or about the y-axis: you end up pointing in the same final direction, but in one the object will be rotated about the x-axis compared to the other.

You can obviously rotated about any vector in the y-z plane, and each one will produce a differnt final rotation.

The workaround posted basically just says "alright if youre diametrically opposite, we will rotate you about the z-axis"

Azelda