love.errorhandler issues

[grump]

A faulty love.errorhandler function throws a filesystem error:

Code: Select all

function love.errorhandler(msg)
	print(msg)
	throw.error() -- error, throw is nil
end

error("why filesystem error?")

An "attempt to index global throw (a nli value)l" error is expected here, but I get this instead:

Code: Select all

main.lua:6: why filesystem error?
Error: [string "boot.lua"]:253: Failed to initialize filesystem: already initialized

Is this a bug?

There is also no default love.errorhandler:

Code: Select all

print(love.errorhandler)

Code: Select all

nil

Is it possible to invoke the default errorhandler from a custom handler or is a verbatim copy of its code required?

[pgimeno]

The "already initialized" error message itself seems to be a subtle bug that may not be worth fixing. But what you're facing seems to actually be a documentation problem. A closer read of the default function gave me the hint.

This works:

Code: Select all

function love.errorhandler(msg)
  return function()
    print(msg)
    throw.error() -- error, throw is nil
    return 1
  end
end

error("why filesystem error?")

The default function is actually stored in the deprecated love.errhand. From boot.lua:

Code: Select all

                local errhand = love.errorhandler or love.errhand

Edit: For reference, here's boot.lua as is stored in the code: https://paste.scratchbook.ch/view/ff06bf36 so that you can actually see the line numbers that error messages refer to. Not sure why newlines are removed. Maybe for historical reasons, because if it's to save bytes, a 0.6% saving doesn't seem worth the obfuscation when looking for line numbers in the source.

[grump]

Thank you for checking the code. Should've done this on my own, derp.

I decided to replace debug.traceback to solve my problem (getting usable tracebacks from moonscript), and leave errorhandler alone for now.

The "already initialized" error message itself seems to be a subtle bug that may not be worth fixing.

It's no showstopper, just confusing and makes it hard to find the error in your handler. I believe I've seen this error before, in a different context, but I can't remember the details.