next up previous contents
Next: 3.3.5.0.1 Sample Up: 3.3 Automation binding Previous: 3.3.4.2 Calling Lua from   Contents

3.3.5 Exception Handling

When a run time error occurr when using LuaCOM's methods or objects, there are two possible actions LuaCOM can take: The run time errors can be divided into three types: The third type of error is always translated into a COM exception returned to the server. To ease debugging, these errors are also logged (if the logging facility has been activated), as the server can silenty ignore these exceptions, specially in events. If the LuaCOM library is compiled with VERBOSE
defined, then a lot of informative messages are logged and all errors are displayed within a dialog box. This helps debug errors inside events on the fly, as these errors are commonly ignored by the server. Notice that this options slows down LuaCOM and can generate very big log files. The behaviour of LuaCOM for the other two types can be customized. There is a table called config inside the LuaCOM table. This table holds three fields related to error handling:
abort_on_API_error
if false, LuaCOM silently fails on errors inside API calls. This is NOT true for errors caused by supplying bad parameters: these always generate calls to lua_error. The default value for this field is false.
abort_on_error
if false, errors inside method calls and property accesses are also ignored, possibly return nil where a return value is expected. The default value for this field is true.
last_error
every time a run time error occurr LuaCOM sets this field with the text describing the error. This field can be used to check if some operation failed; just remember to set it to nil before the operation of interest.


Subsections
next up previous contents
Next: 3.3.5.0.1 Sample Up: 3.3 Automation binding Previous: 3.3.4.2 Calling Lua from   Contents
Fabio Mascarenhas de Queiroz 2005-06-06