Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008601opensim[REGION] Script Functionspublic2019-10-17 08:292019-10-18 02:49
ReporterBob Wellman 
Assigned To 
PlatformOSOS Version
Product Version0.9.0.1 
Target VersionFixed in Version 
Summary0008601: [FEATURE REQUEST] add a new on_error event
DescriptionCurrently if a script generates an error this causes a message describing the error on the debug channel. However the script has no way of knowing that it has caused an error so may continue to cause the error.

Take the example of a timer in a script that does llRegionSay(0,"some text") every few minutes. It will continually cause debug messages every few minutes rather than take action to stop being a nuisance.

Having a new event called on_error(string msg) would be useful in solving this. When the script causes an error it should trigger the on_error event in that script and send the message to that event for handling. The script could then decide what to do (possibly to alert the necessary persons and maybe switch state to a shutdown state).
Steps To ReproduceRun a script as per the above example and see the continual debug channel activity.

The person capable of solving the issue is not necessarily present in the sim to get the debug message either. So resources are wasted on running this bad script for no real benefit.
Additional InformationThe above example is one that could be predicted by the scripts author, but I used it to demo that any command may cause a debug loop. Use of os functions where they are not allowed is something the script author could not predict so maybe would be a better justification for this. However my solution is a one size fits all one I think.

This on_error event could be in addition to sending the error on debug or better yet if the script does have this event only send to the on_error event and let the event decide who to tell. If there is no on_error event in the script send to debug channel as now. This means that scripts not meant to handle their own error work as now.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim)
Physics EngineBulletSim
Script Engine
Mono VersionNone
Attached Files

- Relationships

-  Notes
UbitUmarov (administrator)
2019-10-17 08:42

Sorry not viable in current engines. In several cases the excution context can't be safely recovered.
Adicionaly The try/catch we most likely will have avaiable on Yengine will provide a more flexible error handling.
UbitUmarov (administrator)
2019-10-17 08:51

"Currently if a script generates an error this causes a message describing the error on the debug channel. However the script has no way of knowing that it has caused an error so may continue to cause the error."

this only happens using Xengine. On Yengine the script will need a reset to work again
We may change Xengine (again) to do the same.
Bob Wellman (reporter)
2019-10-18 02:29

Let me first respond to your last comment as its an obvious answer.

So now Yengine sends a message to the debug channel and broadcasts it to everyone (or the owner only depending on config). Your improvement is it now doesn't repeat to reduce spam. So if the owner is not present first/only time the message is broadcast he never knows about the error. Do I have that right?

If so can you see why that is not a sensible solution?
Bob Wellman (reporter)
2019-10-18 02:49

Now let me answer your first comment.

I am happy that you are considering try and catch mechanisms. This will greatly help with predictable issues. The case of an os function that may be rejected when it is run some places and not others due to the sims config should use a try catch method which means the script can recover itself.

However we still need a catch all mechanism for unpredictable issues.

The example of the llRegionSay(0,"some text") I gave above is a case in point. My script was written and running at a time when using this command on channel zero was allowed. So even if try and catch had been available at the time there was no reason to suspect an error could occur. therefore I wouldn't have written a try and catch for it. This ran for a long time until I upgraded opensim in a region running it. You (ubit) had changed the rules for llRegionSay to disallow my use of it so the unpredictable happens and it spammed everyone.

This is why we need a catch all mechanism (on_error) to catch unpredicted errors. Otherwise to catch all errors, I would have to write try catch for everyone function call just in case it changed. I think you would agree that is not whats wanted.

So to summarize please give us try/catch and on-error. I foresee people using on_error being a way for people to deal with unexpected failure rather than recovery of the script. The script writer can then best decide how to inform people that a failure occurred. It may be creating floating text on the prim concerned that an error occurred. It may be to http a script writers php error logging system (given good HTTP headers that could help him pinpoint where the error occurred in the HG). It may be to send a message to the sim owner. It may be all of the above. This would be for the script writer to decide. He just needs an event that informs something went wrong and what error message it caused.

- Issue History
Date Modified Username Field Change
2019-10-17 08:29 Bob Wellman New Issue
2019-10-17 08:42 UbitUmarov Note Added: 0035733
2019-10-17 08:51 UbitUmarov Note Added: 0035734
2019-10-18 02:29 Bob Wellman Note Added: 0035735
2019-10-18 02:49 Bob Wellman Note Added: 0035736

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker