[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: fine-grained lua_pcall() error processing
- From: petah <lua@...>
- Date: Wed, 13 Mar 2013 03:43:12 +0100
>> 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.