Throw an error from C++ with location returned in the error message

[rpatters1]

I have a c++ function like this:

void throw_error(const char* message)
{
   throw std::runtime_error(message);
}

int lua_callable_func()
{
   throw_error("This function is not currently supported.")
}

And a Lua script like this:

function my_function()
   lua_callable_func()
end

my_function()

The script aborts cleanly with the error message, as it should. But the message is missing the filename and line number in the Lua script where it happened. Is there any way to have that show in the error message as well?

[rpatters1]

Actually, it turns out that it has to be from a registered class. A straight function call into a namespace does report the file and line number. So the pared down scenario appears to be:

class RegisteredClass // this class is registered in LuaBridge
{
public:
   RegisteredClass() {} // this constructor is registered in LuaBridge
   unsupported_method() // this method is registered in LuaBridge
   { throw std::runtime_error("method not supported."); }
};

local instance = RegisteredClass()
instance:unsupported_method() // causes runtime error without file location info

The difference appears to be between line 379 and line 428 of FuncTraits.h. Line 379 reports file location info but line 428 does not.

[rpatters1]

Further info. For some reason, Namespace methods are called via luaV_execute but Class methods are called via luaD_precall. This appears to be because of a difference in how Namespace::addFunction registers the function vs. how CFunc::CallMemberFunctionHelper registers the function. I haven't been able to narrow it down further.

I am using the Lua 5.2.4 codebase.

[rpatters1]

A reply seems to have been deleted, so maybe it was not intended for this thread. But perhaps I should add that I am trying to hook up a C-callable framework to Lua. While accessing the Lua-state from within the routine that throws the error is not impossible, it would introduce a lot of tortuous macro logic that I would like to avoid.

[rpatters1]

I'm closing this and opening a new issue with a working test case to illustrate the problem.