sinisterchipmunk / jax

Framework for creating rich WebGL-enabled applications using JavaScript and Ruby
http://jaxgl.com
MIT License
96 stars 16 forks source link

Improve error reporting mechanism #33

Closed sinisterchipmunk closed 12 years ago

sinisterchipmunk commented 12 years ago

Jax's current error handling sequence looks something like:

  1. Throw an instance of Error.
  2. Catch the instance of Error elsewhere in Jax -- usually at the top level of Jax.Context#render, Jax.Context#update, or Jax.Context#initialize.
  3. Pass the error into Jax.Context#handleError(phase, error), where it will be dispatched to the current controller, logged and/or re-raised.

This is performed by a confusing set of try/catch statements sprinkled throughout the framework.

The next version of Jax should instead replace the first step (throwing the error) with a call to Jax.Context#reportError(level, message) or something similar. This way, the stack trace will be more cross-platform because it does not need to be noted or modified (it is already part of the call to reportError), and the entire error reporting process is less confusing. The #reportError method can then dispatch the error to controllers, or log it to console, or just throw it if it's catastrophic. The various try/catch blocks in Jax can then be removed, because with this paradigm, if an error is raised thrown at all then it is fatal and should rarely, if ever, be caught.

Additionally, currently if the error is encountered in the initialize phase, the handleError method infers that it must be catastrophic; all other errors are deemed rescuable, though they usually stop the render or update thread. The new mechanism should explicitly require an argument indicating whether or not the error can be recovered from, and this argument should be passed into the current controller so the application developer can determine how best to handle it.

sinisterchipmunk commented 12 years ago

Ended up going a different route. Both the existing and proposed implementations were too heavy-handed. Sometimes simplicity is best.

Now, Jax.Context just hooks into window.onerror. Its callback checks whether the current controller or ApplicationController have a error method and calls it if so. If the return value from the controller is true, the context resumes rendering; otherwise rendering is halted.

The nicest thing about this approach is that stack traces aren't tainted, and the error bubbles up if the controller didn't handle it. (It bubbles up either way in Chrome, but that doesn't seem to hurt anything.)

See 159ea5c51fa782639c8f6059bc423c362cc1fe59.