As most developers of complex systems know, it is often a huge challenge to build in the ability to handle unexpected events. The designer should always be asking what the software should do when events like the following occur:
abort button during a complex operation.
The scripting engine within DCSS attempts to handle unexpected errors in a consistent way without requiring the script writer adding a single line of code. The writer of the script only needs to write the script as if everything is working normally to obtain the default error handling behavior. However, the default handling of exceptions may be insufficient in some situations, and the script writer can write additional code to handle these special cases.
All un-handled exceptions within a script will do one of two things, depending on the script type:
This will allow the caller to be able to determine the reasons for scripted operation's failure.
aborted status to the caller.
This is a system deficiency that will be overcome in later versions of DCS. The error message should be generic in the same was as the scripted operations.
Currently the scripting engine design is very picky about errors on motors and may seem heavy-handed. However, the purpose is to prevent possible hardware damage instead of allowing a script to grind onward by repeating a move again and again. The script writer should be careful about added exceptions handlers for the code that could override a default system behavior that was designed with safety in mind. Often it is best to allow the script to exit and force the user to resolve the problem.