>
The whole point of lua_pcall() is that it always returns, except when
> it executes, directly or indirectly, some misbehaving "C" code.
It seems I can create a simple Lua code that does not return after pcall:
co = coroutine.create(function () my_pcall(coroutine.yield) end);
coroutine.resume(co);
print(coroutine.status(co)); -- dead ... but no exception or other issue
Corresponding C code for "my_pcall" - I would not think this is "misbehaved":
int my_pcall(lua_State *L)
{
lua_pcall(L, lua_gettop(L)-1, 0, 0);
assert(0);
return 0;
}
Maybe Lua raised an error in coroutine.yield (where does this error go?).
But it still did not continue after lua_pcall - the assert is not triggered.
But this is exactly why I'm asking.
Is there a test code that would behave differently?
Will it really break some test code?
And if it is not possible to build something "around" Lua, I would need to build it "into" it:
> Could a pcall wrapper be a good solution for you? Something like (not tested):
> ...
If the solution with a setjmp/longjmp "around" Lua works without (unacceptable) side effects, I would not modify anything "inside" Lua.
I already thought about modifying pcall - not in Lua code but in C code. Either by creating my own pcall (and xcpall), or by modifying lua_pcallk in lapi.c if required.
Something like "if the message argument of error(message) is my userdata type, then re-throw this exception".
With an appropriate creation of "my userdata" objects, this could effectively introduce some kind of "typed exceptions" and "typed catch"..
But this would actually be much more than my requirement right now - something that I would rather deposit on a Lua 5.5 wish list (if there is something like this) - because introducing such a concept can do much more than I need now and seems a little like "using a sledgehammer to crack a nut".
Probably this "rethrow" concept with a simple convention of what to rethrow is a solution with less undesirable side effects and better in line with the architecture?
