Attempt to index a nil value in a script

Question

I'm trying to write a lua script to assist in modifying a game, and it keeps breaking on one particular line of one of my assistant libraries.

odfWriter.lua:

require 'loopsetup'
require 'ioWriter'
local open = {}
odfWriter = class{
    writer = false
}
odfWriter[open] = false

function odfWriter:open(name)
    if not self[open] then
        self.writer = ioWriter()
        self.writer:open(name)
        self[open] = true
    else
        error("tried to open an already open writer")
    end
end

function odfWriter:write(args)
    self.writer:write(args.Key .. " = ") --<-- error is here, when trying to access args
    if args.Type == "seqstrings" then
        for k,v in pairs(args.Value) do
            self.writer:write("\"" .. v .. "\" ")
        end
    elseif args.Type == "string" then
        self.writer:write("\"" .. args.Value .. "\"")
    elseif args.Type == "seqnumbers" then
        for k,v in pairs(args.Value) do
            self.writer:write(tostring(v) .. " ")
        end
    elseif args.Type == "number" then
        self.writer:write(tostring(args.Value))
    elseif args.Type == "boolean" then
        if args.Value == true then
            self.writer:write("1")
        elseif args.Value == false then
            self.writer:write("0")
        end
    end
    self.writer:write("\n")
end
function odfWriter:close()
    if self[open] then
        self.writer:close()
        self.writer = false
        self[open] = false
    else
        error("tried to close an already closed writer")
    end
end

loopSetup.lua

-----------------------------------------------------------------------
--  file        : loopsetup.lua
--  description : provides global access to all of the (known) members
--                of the loop.simple code (for easier access)
-----------------------------------------------------------------------
require 'loop.simple'
class = loop.simple.class
classof = loop.simple.classof
initclass = loop.simple.initclass
instanceof = loop.simple.instanceof
isclass = loop.simple.isclass
memberof = loop.simple.memberof
members = loop.simple.members
new = loop.simple.new
rawnew = loop.simple.rawnew
subclassof = loop.simple.subclassof
superclass = loop.simple.superclass

ioWriter.lua:

local loaded = require('loopsetup')
assert(loaded, 'loopsetup not loaded')
local open = {}
ioWriter = class{
    stream = false
}
ioWriter[open] = false
function ioWriter:open(name)
    if not self[open] then
        self.stream = io.open(name, "w")
        self[open] = true
    else
        error("attempted to open an already open writer")
    end
end
function ioWriter:write(str)
    self.stream:write(str)
end
function ioWriter:writeLine(str)
    self.stream:write(str .. '\n')
end
function ioWriter:close(self)
    if self[open] then
        self.stream:flush()
        self.stream:close()
        self.stream = false
        self[open] = false
    else
        error("attempted to close an already closed writer")
    end
end

test code:

require 'loopsetup'
require 'odfWriter'
local odf = odfWriter()
odf:open('test.odf')
local line1Data = {
    Type = "seqstrings",
    Key = "engineTargetHardpoints",
    Value = {"hp01", "hp02", "hp03"}
}
odf:write(line1data)
odf:close()

Why do i have this error when i am clearly passing in a valid table to odfwriter.write?

Answer 1

At least in your test code, you have a typo:

line1data ~= line1Data

You also have a typo in ioWriter.lua in the close method:

function ioWriter:close(self)

should be

function ioWriter:close()

Answer 2

You haven't explicitly checked that everything implementing odf:open() succeeded. My concern is that it looks like the whole flow control in of odf:open() seems to assume that everything succeeded. Is it possible that it didn't, and as a result that at the line indicated the error is caused by attempting to index self.writer containing nil?

It could be nil as opposed to false if odfWriter:open() didn't successfully execute the constructor self.writer = ioWriter() for example. I'm not a regular user of loop, so I might be barking up the wrong tree, but...

If that were happening, it would be easy to get a message that is confused about which index was at fault.

Perhaps dropping calls to assert() in a few choice spots would be productive.