C++ exception handling

[Gedalia Pasternak <gedalia@...>]

Hi List, 

  I'm attempting to hook up the lua_pcall error handling functionality inside of C++. I'm using lua to bind to a large c++ api (via swig) occasionally pointers get out of sync and c++ code will throw an access error. The following code seems to work if a generic error is thrown from swig with lua_error.

static int mytraceback (lua_State *L) {
   //copy of traceback code
}
...
//eval string code
    lua_pushcfunction(L, mytraceback);

    // puts the string onto the stack as a function
    int retval;
    retval = report_load_error(&m_log, L, script_source, luaL_loadbuffer(L,string,strlen(string),script_source));
    if(retval != 0){
        lua_pop(L, 1);
        return retval;
    }

//stack now has 2 items in it: however it appears that since the string function comes off as part of the call 
// the error function seems to now be only one deep,
    retval = report_run_error(&m_log, L, script_source, lua_pcall(L, 0, 0, 1));

There aren't very many examples of lua_pcall with an error handler floating around the net, but I think this is right.
   I had hoped this would allow me to catch c++ exceptions and at least find out what lua code had triggered them.. However when the exception goes off it winds up in the try catch block in luaD_rawrunprotected and the custom error function never goes off. All I get is a message '(error with no message)' 

I'm compiling lua with visual studio 2008/vc9 in c++ mode, there have been some changes in exception handling in vs 2008/vc9, and I've been compiling with /EHa (http://msdn.microsoft.com/en-us/library/1deeycx5%28VS.80%29.aspx) Although I'm a bit fuzzy on what the right settings should be in terms of lua. 

Thanks for any input.
-Gedalia Pasternak
-- 
---------------------------------------------------------------
http://www.gedalia.net
---------------------------------------------------------------
Fight Entropy!!!  Fight Entropy!!!  Figth Etnropy! !
iFgth Etnrop!y ! giFth tErno!py !  giFt htrEno!p y! --- Well maybe
not...