Errors within playdate.keyPressed() silently fail and remaining code is not executed

SDK Bug Reports
1

Reproduce

  • Call a non-existent function within function playdate.keyPressed(key)

Expected

  • Error should be raised at either compile-time, or run-time

Actual

  • Code execution stops at the line of the function call
  • Code from there until the end of the current function is not executed

Screenshots

Look at the following code:

Screen_shot_2021-05-24_at_10.43.25
Screen_shot_2021-05-24_at_10.43.25562×600 86.3 KB

Notes

  • Player:moveShadow() is a class function I had since commented out
  • same happens if I replace the above call with a local function like abcde()
  • important: the code in the screenshot is in my main.lua inside of function playdate.keyPressed(key), so outside of any class/OOP (thanks to Nic on Discord)

Also

  • Player is defined as class('Player').extends(playdate.graphics.sprite)

Regression tests

Happens in all of:

  • 1.0.8 nightly 113111 (courtesy of @dave)
  • 1.0.8
  • 1.0.0
  • 0.12.0
  • 0.10.0
  • 0.9.0
    (I skipped some point releases)
    (my code won't run in older versions)
2

Above issue has been edited/updated

3

So I looked a bit into this issue and it seems some callbacks don't report error as expected (probably called using pcall() but doesn't handle the error?)

Pocking around it seems the following functions don't report error
playdate.keyPressed()
playdate.keyReleased()
playdate.gameWillTerminate()
playdate.deviceWillLock()
The callbacks for system menu items like playdate.menu:addMenuItem()

playdate.sound.micinput.recordToSample() callback reports the error but it is incomplete, the file or line number are missing.

and an error in playdate.debugDraw() will crash the simulator :playdate_dead:

I did not test all the callbacks so this is not exhaustive.

1 Like
4

I added a fix for keyPressed/Released(), then I saw Nic's message. I've got a fix in now for the debugDraw() crash. For the others I think it'll just be a matter of replacing the lua_pcall()s with our function that first puts debug.traceback() on the stack as an error handler. That's got a non-zero chance of adding mystery bugs so I'm going to push that til after 1.1 so I don't hold it up or necessitate an emergency 1.1.1

1 Like
5

Sounds good Dave. Thanks

1 Like
6

aha! It looks like lua_call() is what we want if there's already an error handler at the top of the stack. That'll avoid some unnecessary overhead.

1 Like