Good practices

This article will try to explain some good practices, that will help you get going faster and easier find the solution when a problem occurs.

Always check return values for registrations

When configuring the script engine you should always check the return values, at least in debug mode. All error codes are negative so a simple assert( r >= 0 ) where r is the returned value is sufficient to pinpoint where the configuration failed.

If a function failed during the configuration, the Build method will always fail with a return code of asINVALID_CONFIGURATION. Unless you already verified the error codes for all the configuration calls, it will not be possible to determine what the error was.

// Verifying the return code with an assert is simple and won't pollute the code
r = engine->RegisterGlobalFunction("void func()", asFUNCTION(func), asCALL_CDECL); assert( r >= 0 );

assert() can safely be used with engine registrations, since the engine will set the internal state to invalid configuration if a function fails. Even in release mode the failure is discovered when a script is built.

Use the message callback to receive detailed error messages

The return code from the register functions, Build, and CompileFunction, can only tell you that something was wrong, not what it was. To help identify the exact problem the message callback should be used. The script library will then send messages explaining the error or warning in clear text.

See Message callback for more information on the message callback.

Always verify return value after executing script function

The VM can provide detailed information on any exception that occur in the script, for example in which function and line of code the problem occurred. It is also possible to enumerate the callstack and even the local variables.

See Exception handling