-
February 1st, 2019, 23:33 #1
Coding Inconsistency that Might Cause Invertant Error (CoreRPG)
In the masterindex_window.lua file of the CoreRPG ruleset (v3.3.7), at approximately line 239 is the following function:
Code:function clearFilterValues() if fSharedOnly then filter_sharedonly.setValue(0); end if fName ~= "" then filter_name.setValue(); end for kCustomFilter,_ in pairs(aCustomFilters) do if aCustomFilterValueControls[kCustomFilter] then aCustomFilterValueControls[kCustomFilter].setValue(""); end end end
The issue is, if there are custom filters defined (in aCustomFilters{ }) for a particular field of a recordset, if the corresponding control has not instantiated yet, or was never created, when clearFilterValues() is called then an error will be thrown. And it might not really be an error, just an issue with inconsistent coding.Current Projects:
Always...
Community Contributions:
Extensions: Bardic Inspiration, Druid Wild Shapes, Local Dice Tower, Library Field Filters
Tutorial Blog Series: "A Neophyte Tackles (coding) the FG Extension".
-
February 7th, 2019, 00:17 #2
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,557
Minty,
I've gone back and forth a bit on the best way to write the code to minimize user errors, but also not to gloss over errors that indicate a real issue that should be reported.
A few years ago, I started bracketing everything with safeguards as you noted above. However, what I found is that this often obscured Lua issues, so that they were not reported and were harder to debug. I've moved away from adding safeguards, unless I know for sure that the function should accept and ignore nil values.
Regards,
JPG
-
February 15th, 2019, 04:46 #3
Thank you for responding Moon Wizard. I too have been wondering about the wisdom of defensive coding. I hadn’t thought about “issue hiding”. Many users might not observe a subtle error, when they’re in the heat of the campaign. Only the very vigilant are going to catch and report such problems. It can protect the developer from catastrophic failures, but at what eventual cost. And a twinkle comes to my eye when I think of how much easier it is to figure out the problem when you get a number compared to nil error, in bright red, in the console versus a user saying, the number just isn’t right. Where do I start? I need to weigh your comments and figure out where the happy medium is in my work. Thank again.
-
February 18th, 2019, 01:19 #4
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,557
It's less about users not reporting errors (which is a separate item), and more about getting the errors to report to the console while in development so that you can fix them.
Regards,
JPG
-
February 18th, 2019, 05:06 #5
I’ve done a major rewrite and refactor of the code in my Druid Wild Shape extension. I’m still striving for that happy medium. After reading your suggestions I find myself less likely to wholesale safety-bracket code. Particularly, function parameters. If I’m overriding a ruleset function I’ll likely trap nil valued parameters, since I know what I want in the parameters but I might not be familiar enough with the ruleset code to know what I might get. Parameters, from code that I’ve written, I know what I should get, so I’m letting those errant nils pass through to crash execution, letting lua, as you say, help me catch those errors. Thanks again for the insights.
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks