Re: fine-grained lua_pcall() error processing

[petah <lua@...>]

>> Is it possible to get more structured information from a Lua error
>> callback than a "mangled" string generated by luaL_error()/lua_error()?
>>
>
>As far as I know, it's not.

Would there be some lua_State trickery to uniquely identify where luaL_error() was called from? Maybe some twisted native (machine language) stack walk? The daemon currently uses wxWidgets (base) so can use x-platform functions.

>> If not, is there a less dicey way to reduce an error string to a discrete
>> enum than cascading if/else regexes?
>
>Without patching ldo.c, again, not that I know of.

Ok. Regexing error strings seems pretty dangerous anyway; no unit test could ensure its safety and it's clearly an "anti-pattern".

>> If not, is there code out there (whatever the language) to extract a
>> robust regex mapping table from the Lua VM source code?
>
>That's a fascinating theoretical question.  I suspect the answer is "yes,
>but it's not worth the trouble."

I guess "worth" depends on how costly bugs can be :)

Maybe in a new Lua version the different lua_error() invocations could be centralized in a separate #include with one #define per error type, which wouldn't affect functionality.

Too bad Lua doesn't use its own error() model to throw an error object/table before flattening it to a string. Error handling isn't performance-critical so making some lower-level functions client-overridable shouldn't have downsides.

>> My debugger is C-only (no extraneous Lua) and I'd really like to avoid
>> patching the Lua VM.
>
>The Lua source is designed to be easy to patch -- particularly where error
>handling is concerned.  (Grep for the macros LUAI_TRY and LUAI_THROW.)

It seems luaD_throw() is called after the error string is constructed by a bunch of upstream sprintf() macros, so C++ exceptions wouldn't provide more information than longjmp()s. The Lua VM doesn't have code to build an error struct/object; it generates an error string directly from the error location. Adding an enum to the string would make a huge difference.

>Good error handling is a wonderful thing; but of
>course, it's hard to do without deviating from "clean C".  But if you're
>willing to compile the sources as C++, the hooks are easy to write.

I understand but my employer agreed to open-source the debugger with the promise it'd give them visibility and help recruiting Lua scripters. Patching the VM would make the debugger useless to anyone using pre-built Lua libs.

I may have to patch it in the end anyway but it seems a shame given how much built-in debugging functionality Lua already has.

thx,

-- p