catch errors in setup.lua about hammerspoon HOT 11 CLOSED

OOI do you have an idea of how this would work? I was wondering about putting all of the setup.lua work in a function and then xpcall()'ing it, like we do at the end of the file for init.lua?

from hammerspoon.

MJLua.m now pcalls setup.lua, surely we can have error handling there? waves hands some more

from hammerspoon.

Describe "just sits there"... is the console accessible, but just doesn't take input? pop up a dialog that won't go away? Or maybe better, what typo should I introduce to reproduce the effect myself?

I ask because I have had weird issues creating some of my previous modules in which error catching and providing bail outs was highly dependent upon the order in which certain things occurred, and I want to see if I can figure out what minimally MUST work to get usable error messages and/or make the situation recoverable (assuming you know what you're doing).

from hammerspoon.

If you cause some part of setup.lua to want to throw an exception, nothing seems to handle it and the app gets a bit stuck and may also crash entirely.

from hammerspoon.

Most likely it comes down to one of two possibilities:

1. it's a syntax error, and then line 92 in MJLua.m is your likely culprit: luaL_loadfile(L, [[[NSBundle mainBundle] pathForResource:@"setup" ofType:@"lua"] fileSystemRepresentation]);
   If an error in parsing occurs, it's return code isn't LUA_OK, then what it pushes onto the stack is a string (the error) and not a function, so the eventual lua_pcall fails, and again, no check for the results is done.

Not much we can do with the console at this point, but we could pop up a nsalert and exit gracefully, rather than crash.

2. it's a logic/programming error, and then what I posted above might apply...

Here, the console might be usable if at least the print global has been dealt with.

I can try and come up with some example cases and test this theory later, if you like.

from hammerspoon.

I've pushed up 0b027f8 to refuse to proceed starting the app if setup.lua can't be opened or parsed.
The logic/programming error case is much trickier to deal with. I suppose it's possible that somehow setup.lua/init.lua ends up stuck in a loop and there's not a huge amount we can do about it, short of spawning a watchdog thread that circles back and kills the app if it hasn't initialised in a reasonable amount of time.

from hammerspoon.

@Habbie Do you think that 2) outlined by @asmagill needs any attention here? I'm not sure there's much we can reasonably do to defend against logic errors (like infinite loops) in peoples' init.lua. We're covered against syntax errors in setup.lua now. Do we think that is sufficient to close out this issue?

from hammerspoon.

I presume we are also covered against syntax errors in init.lua now?

For loops and such, I don't have better ideas than watchdog-like things. May want to file that separately, not sure it's necessary for 1.0

from hammerspoon.

I think we were always covered against syntax errors in init.lua

from hammerspoon.

I believe so as well!

from hammerspoon.

Cool, then I shall close this issue. We can revisit the halting problem later, if it becomes important, but ultimately it's going to be nigh on impossible to solve completely, IMO.

from hammerspoon.