Please mind that wrapping code in a try-block will send (at least some) JS-engines directly into interpreter mode (no compile-mode, no JIT-mode) and this will have severe effects on the execution speed. I would not recommend this for production!
back
1 comments
Do you have details on which engines will have this issue?
In the actual Bugsnag notifier we avoid adding try/catch in Chrome/Opera because they don't need it (it also breaks "stop on unhandled exception" in the console).
To my humble knowledge this (interpreter mode) also applies to FF (which would be handled in the case of this application by the error-event anyway). I would consider it at least as a "legacy behavior". I think there is no JIT with try-blocks with any JS-engine.
I would suggest to do some speed tests with and without this wrapper.
Generally I would recommend to use a try-block only for some very small portions of code, if at all ... don't use them as a general tool ...
----
Some references:
* "In particular, the optimizing compiler [V8] currently bails out on functions with try {} catch {} blocks!"
http://www.html5rocks.com/en/tutorials/speed/v8/
* JIT, try, catch, see the "Browserscope" at end of page (mind the extreme performance gain for normal functions without try-catch with Chrome 31/32 -- yes, named functions are still the speediest):
Thinking a bit further, but this is pure speculation (and quite over my level of insight into JS-engine-interna):
window.onerror gives you essentially a post mortem dump, as gives you the error message in the console (which now seems to be routed to the error-event). try-catch is essentially different in that it allows you to stay in the same execution context (call-stack, scope-chain, etc). It may well be that there is also a difference, when defining an error-eventListener inside a closure, as this would result in the same contextual necessities as a try-catch-clause (not in every aspect, but in some). Again, I would recommend some performance tests.
Thanks for your input :). I'll definitely do some more rigorous testing — so far I've just run a few test suites and gone "looks about the same".