Coding Inconsistency that Might Cause Invertant Error (CoreRPG)

[Minty23185Fresh]

In the masterindex_window.lua file of the CoreRPG ruleset (v3.3.7), at approximately line 239 is the following function:

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 "if" statement highlighted in red is not present in the code. Elsewhere in the file there are similar constructs where the simple test is performed prior to attempting to index aCustomFilterValueControls{ }. E.g. ~line 503 in rebuildCustomFilterValues() and ~line 514 of rebuildCustomFilterValues(). So the test has merit.

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.

[Moon Wizard]

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

[Minty23185Fresh]

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.

[Moon Wizard]

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

[Minty23185Fresh]

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.