JS stacktraces. The good, the bad, and the ugly.(blog.bugsnag.com)
blog.bugsnag.com
JS stacktraces. The good, the bad, and the ugly.
http://blog.bugsnag.com/2014/01/12/js-stacktraces/
2 comments
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!
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).
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):
http://jsperf.com/try-catch-jit/2
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):
http://jsperf.com/try-catch-jit/2
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.
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".
I'd like to try this, but not having a TypeScript definition file is a barrier.
James from Bugsnag here, our notifer is fully open source (https://github.com/bugsnag/bugsnag-js) would gladly merge a pull request!
Good, if I do it I'll put it on Definitely Typed and send it your way to.
https://github.com/borisyankov/DefinitelyTyped
https://github.com/borisyankov/DefinitelyTyped