Re: customizable Lua "panic" behavior

[Edgar Toernig <froese@...>]

Jim Mathies wrote:
>
> [...] I see the exit call in ldo as more of a debug break, something that
> should never happen in "real life"

Exactly.  Reaching this point is a programming error.

> but I can't predict what my users will do in their scripts unless I force
> them into something, or deal with it.

You don't have to predict what they do.  Just make sure that a possible
error is caught.  How do you start the users code?  With dostring/dofile?
Then you are already save!  Executing code with these functions will never
reach the exit in ldo.c.

> I'm hoping the setjmp thing will work cleanly in 4.1.

It can't work!  The lua_state is not working any more.  Its stack and the
frame pointer are pointing to some aborted function and there are no
documented methods to restore them.  The only thing you can do is call
lua_close().

> We have a situation where we do not want to force the user to wrap his
> code in a predefined function.

Why force them.  _You_ make sure errors are caught.  How is the user code
presented to you?  Somehow you have to start it and that is the place you
install the wrapper.  _Any_ setjmp solution can be converted to a lua_call!

I.e:

   if (setjmp(L->exitJmp) == 0)
     somecode
   else
     exitcode

can be converted to:

  static int foo(lua_State *L)
  {
     somecode
  }

  lua_pushcfunction(L, foo);  //[1]
  if (lua_call(0,0))
  {
     exitcode
  }


Ciao, ET.

[1] This call may generate an ERRMEM and thus call exit() because it is
unprotected.  You have to make sure, that enough free memory is available.
Using luaD_runprotected (it's extern but not documented) would remove this
nastiness.