Re: Binding C++ functions that 'throw' exceptions

["Thomas Breuel" <tmbdev@...>]

We're having the same problem, and I asked about this a few days ago; unfortunately, there has been no official answer from the Lua, tolua, or tolua++ maintainers yet.

Unless we hear about anybody else working on an official solution soon, we're probably going to start modifying tolua++ (there are some other features we need as well).  I believe all tolua++ needs is to have a couple of hooks added so that the exception handlers can then be implemented as a loadable tolua++ extension (we're using tolua++ because of its improved garbage collection).

Cheers,
Thomas.

On 8/16/07, RJP Computing <rjpcomputing@gmail.com> wrote:

Hi,

I am using toLua++ to bind a bunch of functions and many of them throw exceptions. Lua / toLua doesn't allow the exception to come back to C++ after it happens. Instead Lua / toLua reports "Cannot convert value to string" which is not useful. I need to have the exception to go to my main application that knows how to deal with that type of exception. Or I need to have the exception re-bundled as a lua_error. I am using Gcc for the compiler on Windows. If I don't compile Lua as C++ I don't get anything except a close of my program. It appears the Gcc has a problem bridging the gap between C and C++ when exceptions are thrown. Are there any ideas on if this can be automated? I don't want to write all the bindings by hand and I have to deal with exceptions.

Now I have created bindings by hand and I can properly catch the exception inside the binding function. All I do with the exception is get the exceptions description and call luaL_error( description ). This works flawlessly. I basically am asking if there is a way to make the generated functions generate try/catch blocks in the generated functions. Or to push the error message from my exception on to the stack so that when lua_pcall() returns it's error number the message will be on the stack as it usually does.

I hope this made sense. Please ask if you need clarification.
--
Regards,
Ryan
RJP Computing