Closed sinisterchipmunk closed 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.
Jax's current error handling sequence looks something like:
Jax.Context#render
,Jax.Context#update
, orJax.Context#initialize
.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 toreportError
), 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, thehandleError
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.