No error messages for most syntax errors

Solar2D General Questions/Discussion
#1

If I misspell a function name (why I don’t like camellCase) or call something with any part of itself that no longer exists or have some off-code somewhere, then any portion of the game following that mistake won’t run and I’ll be left with a game where half the stuff is loaded and half isn’t. Worse yet I don’t know where the problem is, so I’m often looking through the entire doc if I don’t catch it early. To catch these I am often writing print(“runs to this point”) and transferring it around the code until it doesn’t run, at which point I know it’s the thing 1 line above. If using the scene system the declaration order is pretty particular and all over the place, and if the order is wrong the game won’t tell you problem is the table ur putting stuff in doesn’t exist, it’ll just not display half the objects. And an error in one object often shows up as an error in another that is written perfectly, it’s like stage objects with errors will close themselves and pretend to be fine while secretly casting the errors on the next object wherever it might dwell. scene:create() had a function call to add_foe() sitting on its own outside of everything else to generate a test foe, but it would generate a foe every frame…it took me a while to figureout a stage object using a since commented out object’s coordinates in its own table was the problem…that’s crazy mischevious behaviour, and no error messages in sight.

iDontExist(33,33,) --error

iDontExist(33,33) --no error..you don't exist tho so the game will freeze whatever bit comes after
iDontExist(...) --error!??! that's inconsistent
iDontExist(33,33,...) --error!??! that's inconsistent

This has proven to be extremely nefarious. Is there some kind of setting/thing I’m missing I can turn on to check for this stuff?

The error messaging only seems to catch certain things like you have a comma in the wrong place. I can’t remember which, but some of these ‘errors’ are legit in vanilla lua and other lua engines so I don’t know why they would generate errors in solar2d. But the comma example has its own rules, sometimes it allows a comma after a table entry…sometimes it doesn’t…really annoying inconsistencies, at least these generate errors though. I think it was the physics bodies when doing mult-bodies it doesn’t like an extra comma at the end of the final entry, but sprite system is fine with that extra comma…definitely ideal to let you write the extra comma from a commenting out perspective when the entries r long { {}, {}, } vs{ {}, {} }

#2

Hi!

If you want to help things be more consistent, some sample code addressing each issue is probably best.

Each Lua script in the project directory is analyzed before execution. A function that doesn’t exist will immediately trigger an error with the filename and line number of said function. If the function did exist at one point and then its set to nil and you try to call it again it will also trigger an error with helpful information, thus your current sample code out of context is not valid as the function doesn’t exist.

1 Like
#3

Okay I see what you are saying, turns out in my included function list I had a table named debug={} and this was preventing alot of the error messages from displaying. As far as I can tell debug is a reserved variable name, I never ran across such information in the docs (maybe I missed it)…and it’s not in the api as a name so not sure how u are supposed to know this, but if I missed the “reserved names” list for variables I would very much like to know what it is so I don’t run into this again.

This is a decade old, but to my point it’s not in there: AutoComplete List - All functions and Reserved Words. Best idea I have atm is to print(var_name) to test if ‘generic word’ variables like debug can be used.

#4

That one really is unfortunate, there probably should at least be some kind of a warning.

All global variables live in _G table, and you can grab a list like so:

for var in pairs(_G) do
  print(var) 
end

Per Lua docs, you can set a metatable on _G to prevent writing to global scope, but a quick test in Solar2D shows the following:

_G.debug {} -- error triggered from metatable
debug = {} -- no trigger at all

What we’ve come accustomed to, and the general advice is, stay away from global variables, keep things local, and use a module or your own global table if necessary:

--Somewhere in main.lua declare your global table, in the sample below GLO.debug can be used anywhere in your project
GLO = {}
GLO.debug = function()
  print("Debugging")
end
1 Like