

JS stacktraces. The good, the bad, and the ugly. - cirwin
http://blog.bugsnag.com/2014/01/12/js-stacktraces/

======
masswerk
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!

~~~
cirwin
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).

~~~
masswerk
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/](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](http://jsperf.com/try-catch-jit/2)

~~~
masswerk
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.

~~~
cirwin
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".

------
michaelwww
I'd like to try this, but not having a TypeScript definition file is a
barrier.

~~~
foobar2k
James from Bugsnag here, our notifer is fully open source
([https://github.com/bugsnag/bugsnag-js](https://github.com/bugsnag/bugsnag-
js)) would gladly merge a pull request!

~~~
michaelwww
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)

