JS stacktraces. The good, the bad, and the ugly.
blog.bugsnag.com
blog.bugsnag.com
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).
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):
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.