Handle JS errors properly

[Philip]

Our current handling of SpiderMonkey errors is all broken: mostly we assume they don't happen, and if they do we report an error but don't propagate the exception. I've not noticed this being a significant problem in practice, but it's not nice.

I believe the way it's meant to work is (as ​here):

• If a JSAPI function returns JS_FALSE, it has reported an error and thrown an exception; either propagate JS_FALSE back into JSAPI, or use JS_ClearPendingException to catch it.
• To trigger a JSAPI error, use JS_ReportError and return JS_FALSE.

[historic_bruno]

A few related thoughts:

If we plan to keep USE_STRICT enabled, we can remove the ugly hack from the error reporter and not prepend "use strict"; to loaded scripts. Assuming they have equivalent behavior.

Slightly more information could be added to errors by checking the flags for exceptions (JSREPORT_IS_EXCEPTION) or strict warnings (JSREPORT_IS_STRICT).

Something should be done about js "out of memory" errors. It's an ​uncatchable error, but I doubt we want to keep executing the script as if nothing is wrong. Better would be to present a message to the user and end the game, but it seems messy if the error reporter is responsible for that.

[Philip]

If you mean JSOPTION_STRICT, that's completely separate from "use strict". (The latter is standard ES5 strict mode, the former is an old SpiderMonkey-specific feature, and they had an unfortunate name conflict.)