Re: Dealing With Errors in Lua

[petah <lua@...>]

On Fri, 27 Sep 2013 16:04:49 -0300
Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> > ... then again a couple of weeks ago but both lhf and Roberto shot it down (ouch:). [...]
> 
> I am not sure what you mean by "shot it down". If you are refering
> to message [1], I intended just to correct an inaccuracy in your
> description of error handling in Lua.
> 
> [1] http://lua-users.org/lists/lua-l/2013-09/msg00640.html

Ok then may I dispute your correction? (which I realize sounds preposterous):

> > Both luaL_error/luaG_runerror receive only strings, so they do not
> > need to flatten anything. But the real error primitive is lua_error
> > and, internally, luaG_errormsg; both accept any object as the
> > error "message" and do not change that object in any way.

Take ltablib.c
  [ 2105: 2227] 'luaL_error(L, "invalid value (%s) at index %d in table for " LUA_QL("concat"), luaL_typename(L, -1), i);'
or lstrlib.c
  [ 5577: 5632] 'luaL_error(ms->L, "invalid capture index %%%d", l + 1);'

luaL_error() is a vararg "flattener"; of course it receives a fmt string as 1st argument -- and admittedly can't process the full range of printf() syntax -- but still serializes logical data into a string. In the above examples that data gets lost. Even if it only flattened other strings, and no other data type, the possibility (or likelihood, really, since it's handling errors) that some of these string contain random data or any unknown escape sequence, turns what could be a vanilla error handler into a bomb defuser. Trying to delimit arguments with a regex, say, would be pretty dicey.

I'm just advocating that this logical data should be available to the error callback.

cheers,

-- p