Re: Missing error message in panic handler / calling luaD_throw without error message on stack

[Jan Behrens <jbe-lua-l@...>]

On Mon, 10 Nov 2014 11:03:01 -0500
Patrick Donnelly <batrick@batbytes.com> wrote:

> Hello Jan,
> 
> On Mon, Nov 10, 2014 at 9:39 AM, Jan Behrens
> <jbe-lua-l@public-software-group.org> wrote:
> > On Mon, 10 Nov 2014 11:18:57 -0200
> > Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> >
> >> > > Looking into the source code of Lua 5.2.3, I found that in line
> >> > > #93 of lmem.c, the function luaD_throw(L, LUA_ERRMEM) is called
> >> > > #without
> >> > > pushing first an error message on top of the stack. Other
> >> > > calls of luaD_throw, however, push an error message to the
> >> > > stack, e.g. function lexerror() in llex.c, line #110 or
> >> > > function checkmode() in ldo.c, line #635.
> >> > >
> >> > > Is this a bug?
> >> >
> >> > There seems to be a bug, but not there. As lhf pointed out,
> >> > memory errors are handled differently; the error message for
> >> > them is pushed in ldo.c, function 'seterrorobj'.
> >>
> >> The bug is that 'seterrorobj' is not called in the case of a panic.
> >> (For protected calls, the error message "not enough memory" is
> >> returned correctly.)
> >>
> >> -- Roberto
> >>
> >
> > Thank you for this information. I might just push an error string on
> > top of the stack as a workaround before calling lua_newuserdata()
> > until this bug has been fixed.
> 
> An even better solution would be to use lua_pushcfunction + lua_pcall
> so you don't get a panic at all. A panic should not be considered a
> routine error handling mechanism, IMO.
> 
> -- 
> Patrick Donnelly
> 

I do use lua_pcall when calling user code. I just found it easier to
use lua_atpanic when preparing the Lua machine (calling luaL_openlibs,
creating objects that are passed to the user code, etc). If I do not
use lua_atpanic at all, then I'd have to wrap my whole program in yet
another function, e.g. instead of writing...

L = lua_newstate(my_allocator, NULL);
lua_atpanic(L, my_panic_handler);
luaL_openlibs(L);

...i'd already have to encapsulate luaL_openlibs(L) in another
(pcall'ed) function. This makes my code less readable. So I like the
interface that lua_atpanic offers me.

In my case, errors outside lua_pcall are no routine errors, and
terminating the process is the only thing left to do in those cases
(though I assume it's also possible to do a longjmp?).

Using lua_atpanic seemed to be a reasonable choice (as long as it
behaves as specified).


Regards
Jan


-- 
Public Software Group e. V.
Johannisstr. 12, 10117 Berlin, Germany

www.public-software-group.org
vorstand at public-software-group.org

eingetragen in das Vereinregister
des Amtsgerichtes Charlottenburg
Registernummer: VR 28873 B

Vorstände (einzelvertretungsberechtigt):
Jan Behrens
Axel Kistner
Andreas Nitsche
Björn Swierczek