When error in a prototype function, list the function call too.

[bobingabout]

Simple really. With the introduction of my library mod, and switching a lot of my prototype definitions to be inside functions... when you get an error, it can be insanely difficult to track down.

The reason being that the data prototypes error message lists the line the error occured within that functions... I have certain functions where if you have all my mods installed are called over nine thousand times (not quite that many, but it is hundreds), simply telling me that an error occured on line 25 of the file "boblibrary/recipe-functions" isn't that useful. Okay, it does give me the additional information already of what mod it was currently processing at the time, but since it doesn't give me even what file called the function, errors are harder to track down.


Basically, if the game could detect it is currently running a function, then when it errords, it could list the line that called this function (and the line in a function that called that function, and that function that called that function, etc, I think some of my function calls go as many as 5 deep) when generating the error, that would help narrow things down. When debugging, being presented with more information than you need is more important than not being given enough information.

[ratchetfreak]

Simple really. With the introduction of my library mod, and switching a lot of my prototype definitions to be inside functions... when you get an error, it can be insanely difficult to track down.

The reason being that the data prototypes error message lists the line the error occured within that functions... I have certain functions where if you have all my mods installed are called over nine thousand times (not quite that many, but it is hundreds), simply telling me that an error occured on line 25 of the file "boblibrary/recipe-functions" isn't that useful. Okay, it does give me the additional information already of what mod it was currently processing at the time, but since it doesn't give me even what file called the function, errors are harder to track down.


Basically, if the game could detect it is currently running a function, then when it errords, it could list the line that called this function (and the line in a function that called that function, and that function that called that function, etc, I think some of my function calls go as many as 5 deep) when generating the error, that would help narrow things down. When debugging, being presented with more information than you need is more important than not being given enough information.

So you want a lua stack trace printed out on error

[bobingabout]

erm... yes! Actually, it doesn't have to actualy print it to screen, it could just print to log file.

[kovarex]

And using log(debug.traceback()) isn't enough when you already know where is it crashing?

[Rseding91]

And using log(debug.traceback()) isn't enough when you already know where is it crashing?

I believe he's referring to when something goes wrong while running the Lua code you don't know where in the Lua code it went wrong. We don't output the Lua callstack on lua error. We simply display the end message generated by the error.

For instance you could get something like this: "error while running event handler on_tick(): line 512: attempt to compare nil with number"

This message doesn't tell you *how* it got from the on_tick() function to line 512 - it simply tells you it had an error while executing that line. The actual Lua code may have gone through 6 nested function calls and is in the middle of a loop somewhere else that ended on that line.

[Rseding91]

The name of this topic does give me an idea for something else however: when setting up prototypes after all of the Lua calls are done if there's an error it could output the call stack of the C++ code that produced that error. Often errors produced by invalid prototype definitions aren't helpful: "Expected node 'width'" for instance is a common error you might get when a sprite definition is wrong. It however gives zero useful information because "width" is used *all over* prototype definitions.

If the C++ call stack was output it would tell you where in what prototype setup it threw the error which would make it fairly simple to diagnose any error produced.

[ratchetfreak]

The name of this topic does give me an idea for something else however: when setting up prototypes after all of the Lua calls are done if there's an error it could output the call stack of the C++ code that produced that error. Often errors produced by invalid prototype definitions aren't helpful: "Expected node 'width'" for instance is a common error you might get when a sprite definition is wrong. It however gives zero useful information because "width" is used *all over* prototype definitions.

If the C++ call stack was output it would tell you where in what prototype setup it threw the error which would make it fairly simple to diagnose any error produced.

if you had access to the C++ code which the other modders (without a alien egg avatar) don't.

That means that a modder that bumps into one he'll need to go through the forums instead of being able to figure it out himself