Re: customizable Lua "panic" behavior

[Edgar Toernig <froese@...>]

Eric Ries wrote:
> 
> I don't mean to keep banging a dead horse, but this is not workable for me
> in my situation. I only bring this up because I think it may affect others.
> Within the application context that I work in, I develop various lua_States
> as services within the larger application. Users (in C++) of the services I
> provide can get access to various bits of Lua data, and manipulate that data
> (call functions, set values, etc.). Unfortunately, this means that they can
> also do illegal things with the data, 

> [...] and it is not always possible for me to wrap their calls with
> lua_call(). So for these cases, I need a more robust error-handling
> mecahnism than exit()

Well, then say how you want to deal with it!  You _have_ to set up some
wrapper that catches the error and (at least) restores the C stack!
Lua _has_ the ability to do this but if nobody has set up such a wrapper
it has to do something (call exit).  Consider the example from Jim Mathies
with "longjmp(L->exitJmp, 1);"  What do you want to do if the exitJmp was
not initialized?  You call abort or exit.  The Lua authors chose exit.
And any longjmp solution can be implemented with lua_call; it uses longjmp
itself!  And, lua_call not only restores the C stack but the Lua stack too.
Btw, if the C and Lua stack are out of sync your only chance is lua_close!

Using lua_pushcclosure and lua_call is not my favorite either, especially
because lua_pushcclosure may raise an error by itself.  I would like to
see the luaD_breakrun and luaD_runprotected functions (the low-level
routines to handle error raising and catching) renamed and documented
(i.e. lua_throw(L, errcode) and errcode=lua_catch(L, func, ...)).

Ciao, ET.