What the title says. Right now there is only little window with point of error, nothing else is provided.
It is frustrating to have refined code, with high amount of different small specialized methods only to find that such code is very hard to debug.
In such code point of original error has little meaning without knowledge of where it was originally called.
Crude pile of code in single method is actually a lot easier to debug.
I'll probable end up wrapping every event/data.lue in the xpcall for now, but at least pcall did not catch engine generated error on "die()" of a destroyed entity.
Write full LUA call stack in log on critical error
Re: Write full LUA call stack in log on critical error
If it's your code you can always do some error checking with if statements and use error("error message", 2) to 'throw' an error indicating that the caller of the function caused the problem. That can help, and of course pcall can be used to 'catch' those thrown errors see PIL Error Messages and Tracebacks (8.3-8.5 are about errors/exceptions)Dark wrote:In such code point of original error has little meaning without knowledge of where it was originally called.
But yeah...call stacks could be helpful at times
Re: Write full LUA call stack in log on critical error
I did some modding on Teleglitch (which actually uses Lua for it's game logic and doesn't even have official mod support) and the call stack written on an error was an extremely important tool. There's only so much predicting you can do.
Re: Write full LUA call stack in log on critical error
I think error() has it use if you expect an error and know what parameter/condition can cause it, but most of the time you can do little for an unexpected error.
You'll need to place an error() call in method of interest (along with xpcall to catch and print stack trace) then reproduce the error and only then analyze and fix it.
I'll do take a note of throwing error() next time, thanks
You'll need to place an error() call in method of interest (along with xpcall to catch and print stack trace) then reproduce the error and only then analyze and fix it.
I'll do take a note of throwing error() next time, thanks