

Rescue.js - cheeaun
http://rescuejs.com/

======
kulkarnic
I'm still not sure how it catches all unhandled exceptions. I looked at the
source code (<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
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>

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/>.

~~~
cirwin
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>) and the user
context in which it happens makes it considerably easier to fix the problem.

~~~
laughinghan
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?

------
Tichy
Could we start to add some information on what the given js library does in
the HN titles?

------
brunoqc
There's also Sentry (<https://github.com/getsentry/sentry>) which works on the
server side too (with python, node.js, php, ruby and java)

------
tlrobinson
Is this basically what Proxino does? <https://www.proxino.com/>

------
dbloom
It should be possible to get exceptions raised in event listeners too
(including stacktraces) if you wrap the DOM prototypes. I do something similar
in the exception catcher we use at Cue: [https://github.com/Cue/greplin-
exception-catcher/blob/master...](https://github.com/Cue/greplin-exception-
catcher/blob/master/javascript/errorcatcher.js)

Not only does it log stacktraces, but it also breaks Firebug. And you'll find
out that most of your exceptions end up coming from JS injected by shady
toolbars and malware on people's systems :-(.

------
brianr
Also check out <http://ratchet.io> which also supports debug-style logging so
you can, for example, wrap console.log() to debug client-side issues in
production.

------
andrew_wc_brown
We rumbled as well. Not as practical. We made a Star Trek game. <http://the-
glimmer-twins.r12.railsrumble.com/>

Good luck!

------
timmclean
That's a neat use of JavaScript Source Maps. Unfortunately, it looks like you
would effectively need to make your non-minified codebase public. Any plans
for ways to get around that?

~~~
quotemstr
Your source code is not that special. Really. Do you really think you have
some clever trick nobody else has considered, and that you can successfully
hide it behind minification? Come on.

~~~
blcArmadillo
While timmclean's comment does indicate that he was thinking about keeping
your codebase private; most people minify their code to cut down on
filesizes... so his questions is still valid.

~~~
nilved
The question is, but it's answered with source maps. The concern that source
maps allow anybody greater access to your code is not a valid one.

~~~
timmclean
I just did some more reading on source maps. I thought they had far more
information about the original source than they actually do. Thanks!

------
jaip
Looks very much like <http://errorception.com> to me. Definitely a dense
market now, a comparison page would help.

------
mkramb
<http://www.errorify.com/> is also using sourcemaps (and you don't have to
make non-minified code public), with no dependencies (like jquery, ...),
totally crossbrowser and provides optional code rewriting. And has unified
dashboard <http://www.errorify.com/features>

@glesperance 10x

~~~
glesperance
There's one too many 'r' in your first url.

------
troels
When I tried to do this myself, I ran into a problem with lots of errors
happening for reasons exterior to my app - People have strange plugins, that
may fail; if the user navigates away from a page, before all javascript has
loaded, it might cause unpredictable errors. You probably need to filter these
out, to be able to use it for anything.

------
sidchilling
Is this like <http://errorception.com/> ?

------
rorrr
How do you deal with minified JS (which is what you normally have in
production)?

~~~
jabo
They mention that they use source maps
([http://www.html5rocks.com/en/tutorials/developertools/source...](http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/))
at the bottom of the page.

~~~
rorrr
Ouch. Looks pretty complex. Has anybody here tried it? Any feedback?

~~~
benregenspan
If your minifier/obfuscator supports creation of source maps, it's simple. You
just need to set a flag to tell it to create the map along with minified JS
and you're good to go. UglifyJS2 and Closure Compiler are among those that can
create a source map.

