lua stack trace #20

Trass3r opened this Issue Nov 22, 2010 · 3 comments


None yet
2 participants

Trass3r commented Nov 22, 2010

Currently it only shows the error message (at least with LuaState.(doString|doFile))
A stack trace would be helpful.


JakobOvrum commented Nov 22, 2010

This used to be supported in the old LuaD. It's pretty easy to do, the question is how to nicely accommodate both the general case (doString/doFile with a custom error handler passed to pcall) and the most useful default behaviour (use debug.traceback).

LuaState also needs loadString and loadFile, returning LuaFunctions. If LuaFunction was given a general pcall method, there could be some overlap in the two solutions.

Trass3r commented Nov 22, 2010

Well, but what if the debug package shall not be exposed to the user?


JakobOvrum commented Aug 12, 2011

doString/doFile now use debug.traceback (merging with your fork earlier), but this function only exists if openLibs was called. I'd rather like to avoid a convoluted runtime check and instead redesign these functions so the user can easily choose what to do. Any ideas?

JakobOvrum added a commit that referenced this issue Aug 19, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment