3 ms·

I'm still not sure how it catches all unhandled exceptions. I looked at the source code (http://rescuejs.com/rescue.beta.js http://rescuejs.com/rescue.beta.js)

I'm still not sure how it catches all unhandled exceptions. I looked at the source code (http://rescuejs.com/rescue.beta.js http://rescuejs.com/rescue.beta.js) and it only seems to wrap setTimeout, setInterval, jQuery.fn.ready, and jQuery.event.add. What about exceptions in other functions? Or does capturing the e.backtrace have something to do with it? Would love to know (and if this works out of the box, what's to prevent cross-domain scripts from communicating with each other by raising exceptions?)

laughinghan 14y ago
It indeed appears to be unable to catch exceptions that happen in event handlers that aren't attached with jQuery or directly in <script/> tags not wrapped in .ready() events, which is interesting because doing so is totally possible: https://developer.mozilla.org/en-US/docs/DOM/window.onerror https://developer.mozilla.org/en-US/docs/DOM/window.onerror There's an argument to be made for attaching event handlers any way besides using jQuery would be bad practice, but not waiting for .ready() to fire is totally normal for sites practicing Progressive Enhancement that put all the <script/> tags at the end of the <body/>.
- marcins 14y ago
  Only problem with this is that window.onerror isn't available in webkit.
  - masklinn 14y ago
    window.onerror is available in all browsers. The issue of window.onerror is that the information it provides is not very good: there's no stacktrace and there's no detailed info, just a line number and a message.
    - bosky101 14y ago
      errorception 's founder gave a nice talk on all the various techniques here http://errorception.com/slides/jsfoo#summary-so-far http://errorception.com/slides/jsfoo#summary-so-far
- cirwin 14y ago
  We will add support for window.onerror eventually, but there are two reasons we haven't yet done this: 1. window.onerror gives you no backtrace 2. hooking into jQuery.event.add lets us tell you "this error happened when the user clicked that button". We've not yet implemented the UI for 2. (48 hours is not so long as we thought!); but I remain convinced that suitable integration with various frameworks is a much better developer experience than trying to rely on just the error message. Being able to see both the source code where the exception happened (see http://rescuejs.com/assets/screen_341.png http://rescuejs.com/assets/screen_341.png) and the user context in which it happens makes it considerably easier to fix the problem.
  - laughinghan 14y ago
    That sounds great, but what if, for example, you used a library that, following perfectly good practices, intentionally doesn't have external dependencies and hence doesn't use jQuery.event.add nor jQuery.fn.ready, and an exception occurs in it or a callback the page author passes to it?

laughinghan 14y ago

It indeed appears to be unable to catch exceptions that happen in event handlers that aren't attached with jQuery or directly in <script/> tags not wrapped in .ready() events, which is interesting because doing so is totally possible: https://developer.mozilla.org/en-US/docs/DOM/window.onerror https://developer.mozilla.org/en-US/docs/DOM/window.onerror There's an argument to be made for attaching event handlers any way besides using jQuery would be bad practice, but not waiting for .ready() to fire is totally normal for sites practicing Progressive Enhancement that put all the <script/> tags at the end of the <body/>.

marcins 14y ago
Only problem with this is that window.onerror isn't available in webkit.
- masklinn 14y ago
  window.onerror is available in all browsers. The issue of window.onerror is that the information it provides is not very good: there's no stacktrace and there's no detailed info, just a line number and a message.
  - bosky101 14y ago
    errorception 's founder gave a nice talk on all the various techniques here http://errorception.com/slides/jsfoo#summary-so-far http://errorception.com/slides/jsfoo#summary-so-far
cirwin 14y ago
We will add support for window.onerror eventually, but there are two reasons we haven't yet done this: 1. window.onerror gives you no backtrace 2. hooking into jQuery.event.add lets us tell you "this error happened when the user clicked that button". We've not yet implemented the UI for 2. (48 hours is not so long as we thought!); but I remain convinced that suitable integration with various frameworks is a much better developer experience than trying to rely on just the error message. Being able to see both the source code where the exception happened (see http://rescuejs.com/assets/screen_341.png http://rescuejs.com/assets/screen_341.png) and the user context in which it happens makes it considerably easier to fix the problem.
- laughinghan 14y ago
  That sounds great, but what if, for example, you used a library that, following perfectly good practices, intentionally doesn't have external dependencies and hence doesn't use jQuery.event.add nor jQuery.fn.ready, and an exception occurs in it or a callback the page author passes to it?