back

by masswerk·12y ago·view on hn ↗
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

1 comments
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".