4 ms·

JS stacktraces. The good, the bad, and the ugly.

29 points by cirwin 13y ago

michaelwww 13y ago
I'd like to try this, but not having a TypeScript definition file is a barrier.
- foobar2k 13y ago
  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 13y ago
    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
masswerk 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        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".

29 points by cirwin 13y ago

michaelwww 13y ago

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

foobar2k 13y ago
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 13y ago
  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

masswerk 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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".