search

sinisterchipmunk / jax

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

Errors during model init in Jasmine are shadowed by GL errors #40

Closed sinisterchipmunk closed 12 years ago

sinisterchipmunk commented 12 years ago

Operations like Jax.Util.vectorize, automatically called on certain properties like position, can raise errors during model initialization.

In a beforeEach block, when a model is instantiated in Jasmine, and an error is thrown during instantiation or an assertion fails, Jasmine will move on to the actual test. This usually culminates in WebGL errors (such as INVALID_OPERATION), which shadow the original failure. Even though the original error is usually listed in Jasmine output, it's easy to miss behind all of the clutter from the WebGL errors and their backtraces, and it's easy to assume the error is WebGL related and not model related.

It would be much easier to understand if, when an error occurs during initialization, models by default are gracefully render-able, so that WebGL errors are not raised, making the actual error much easier to diagnose. This should also apply to errors encountered during after_initialize.

I don't think this affects a production app in any way, because a production app will usually cease rendering or handle the error in some other way, such that the WebGL errors are never raised because the corresponding code is never evaluated.

sinisterchipmunk commented 12 years ago

I don't think this is an issue now, because Jax master no longer raises GL errors. Since both Chrome and Firefox now log warnings whenever a GL error occurs, it was redundant and unnecessary to raise them again, not to mention it hurt performance. Since the warnings are only warnings, they don't cause execution to cease, and there's no GL error to shadow the others.