Errors don't stop the drawing loop

[Kevinpgalligan]

If an error is raised, it should halt the drawing loop. This is not currently the case. If an error occurs in only a single iteration of the drawing loop, the effect is a single flash of the red error screen, and there's no chance to see what the error was or to click for restarts.

To reproduce the bug:

(defsketch diserr ((i 0))
  (let ((err-or-no (= i 0)))
    (incf i)
    (if err-or-no
        (error "howdy")
        (rect 0 0 50 50))))

[Kevinpgalligan]

Pushed some of my work on this here: Kevinpgalligan@655919b

Copying over the commit message...

* Bugfix: Drawing loop doesn't continue after error.
* Debugger is entered immediately, no click required.
  (Not sure how to detect click without continuing the loop).
* By default, the "setup" method is not called again on resumption
  of the sketch. This may need to be reconsidered, e.g. if copy-pixels
  is enabled then the error screen will persist after. One workaround
  might be to save pixel buffer before writing the error, then restore
  it when resuming.
* There's a new restart, "reset-sketch", that explicitly
  reinitialises all the state of the sketch. And this will trigger
  setup to be called again.

Needs to be tested a lot more: what happens when error is triggered in setup, what happens when copy-pixels t. Also experiment with the different restarts. Etc.

Also, consider if the situation can be improved for (copy-pixels t). It'd be a pain if someone ran their sketch for 1 hour, then an error came and we drew a red screen over their nice picture. Quoting above -- "One workaround might be to save pixel buffer before writing the error, then restore it when resuming". It's also pretty nasty if they select the wrong restart and the red screen persists. Of course, I think that can happen with the current Sketch code: if someone fails to define a setup method (or if the setup doesn't draw a background), then I'm preeeetty sure the red screen will stay.

[Kevinpgalligan]

Some test cases...

Test 1

A square moves from left to right. Error happens after 200 frames.

(defsketch test1 ((i 0))
  (if (= i 200)
      (error "this is an error")
      (progn
        (rect i 100 20 20)
        (incf i))))

Try redefining it with the "bug" fixed before selecting the (sdl2-defined) CONTINUE restart. Unfortunately, the square is sent back to the starting line because redefining a sketch also redefines the state.

(defsketch test1 ((i 0))
    (rect i 100 20 20)
    (incf i))

Test 2

Try moving "bug" out to a function, so we can redefine that function instead of the sketch, and avoid overwriting the sketch state.

(defsketch test2 ((i 0))
    (maybe-error i)
    (rect i 100 20 20)
    (incf i))

(defun maybe-error (i)
    (when (= i 200)
      (error "this is an error")))

Fix the "bug" like so:

(defun maybe-error (i))

Aaaaand, it works.

Test 3

Same thing but (restart-on-change nil), this also preserves the sketch state after fixing the bug:

(defsketch test3 ((i 0) (restart-on-change nil))
    (if (= i 200)
        (error "bug")
        (progn
          (rect i 100 20 20)
          (incf i))))

Test 4

Signalling an error from the setup method.

(defsketch test4 ((i 0))
  (rect i 100 20 20)
  (incf i))

(defmethod setup ((inst test4) &key &allow-other-keys)
  (error "bleh"))

If the CONTINUE restart is selected, the sketch carries on as normal, because the setup isn't re-invoked. If RESET-SKETCH restart is selected, the setup method is called again and the error is re-triggered. This is at least as good as the current behaviour, I think.

Test 5

On to (copy-pixels t). Draw 200 random circles and then trigger an error.

(defsketch test5 ((copy-pixels t) (i 0))
    (when (= i 200)
      (error "this is a bug"))
    (circle (random width) (random height) 10)
    (incf i))

(defmethod setup ((inst test5) &key &allow-other-keys)
    (background +yellow+))

For some reason, when selecting the CONTINUE restart after fixing the bug, the sketch recovers okay but all the circles are gone. It still has the yellow background. This is not what I was expecting, which was either: (1) The error screen stays as the background and new circles are drawn over it, or (2) The last state of the canvas is preserved (maybe 'cause it was in our drawing framebuffer), with all 200 circles, and the sketch continues as normal. So, I need to dig into what's happening here.

(Update with answer: redefining the sketch sets sketch-%setup-called to false, so... that's why the background reverts to yellow and all the circles are gone. That's fine!).

Ideal state of affairs: error screen is drawn directly to the window, doesn't overwrite our drawing framebuffer

Test 6

If the "bug" is moved outside the defsketch body, like in Test 2, then the CONTINUE restart results in the error screen persisting as the background!? Same with (restart-on-change nil).

(defsketch test6 ((copy-pixels t) (i 0))
    (maybe-error i)
    (circle (random width) (random height) 10)
    (incf i))

So, the error screen is being dumped into our FBO, somehow. Not sure how it's visible then...

(Update: this turned out to be a bug in the copy-pixels/FBO stuff! Fixed now, and the entire fix has been merged to the dev branch of my fork).