Error Handling

[shiffman]

Just adding an issue to open the discussion on how to handle syntax errors in code. Some thoughts:

• We have hints / buttons (perhaps when the video goes away) that remind users of syntax and also offer quick means to reset the code to a working state.
• If it doesn't work, at a minimum we show a message that indicates there is a bug in the code and offers helpful general suggestions.
• Ideally we offer specific feedback, i.e. missing a semi-colon, you spelled ellipse() wrong etc. But not sure if this is realistic. See https://www.khanacademy.org/cs for a nice implementation of this.

[scottgarner]

At an absolute bare minimum we should be able to catch an error and offer to reset to a usable state.

At a glance, anything beyond that (did you mean..., etc.) would be totally custom. I'll think on it though. On the plus side, semicolons are optional in Javascript.

[scottgarner]

I've done a bit more work on this. As it stands, I can catch an error without any trouble. The problem is that the error I catch is a Javascript error, not a Processing error, which can get a little confusing.

Here's the current behavior:

1. Any time code is successfully run, it is stored in a cache. Dan's example code should always end up there if nothing else.

2. Later, if an error is caught during a user run, helloEditor.displayError() is called.

3. This function shows a modal window with the option to either restore the code back to the last good run or dismiss it.

4. It also has the ability to parse the JS error with regular expressions if we want to try to catch some common errors ourselves instead of displaying the raw error message.

My worry here is that constant pop-ups will get annoying over time, but the window doesn't have to be full-screen modal. We can show the same thing under the editor or elsewhere.

Most of the work here, I think, would be tons of regular expressions trying to make friendly errors. The other option is to try to parse the Processing code for errors before compiling it to JS, though I think that's an even bigger project.

-S

[shiffman]

@scottgarner I'm not seeing the error window for some reason. This is the code I'm testing with:

void setup() {
   size(500, 400);
}
void draw() {
  background(frameCount);
  rect(100,100,20);
  elipse(20,50,100,500);
}

[scottgarner]

Wow, that was almost a huge problem!

I had only been testing cases without the draw() loop for errors. It didn't occur to me that with the draw, the code is called anonymously by a timer, making it almost impossible to catch errors without reworking parts of processing.js.

I lucked out on a simple fix, which is to manually call draw inside of my try {} when it's available. After quick testing it seems okay, but it's definitely something to keep an eye on.

[scottgarner]

Current status for this:

There is a displayError() function in editor.js which takes a Javascript error and has some initial code to search for common problems and report them in a friendlier way. I'd like to think of a tidier way to do this, but it works for now.

I'm going to assign this to @shiffman for now and work with him to catch common errors and streamline any other aspects of the error system that need work.

[shiffman]

Great, I'll take a closer look at this sometime this week.

[scottgarner]

I've got an idea for a simple translation table. I'll take a quick stab at it and you can let me know if you have any questions when you get a chance.

[scottgarner]

Okay, I've added an error translation table with a few examples. Let me know if you have any questions.

[scottgarner]

Something just occurred to me: Every javascript engine is going to throw its own version of the errors and they'll probably all vary slightly.

[scottgarner]

Taking this off of the milestones leading to launch and marking it as an enhancement.