Rescue.js | Hacker News Reader

Rescue.js

rescuejs.com

164 pointscheeaun42 comments

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?)

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

Only problem with this is that window.onerror isn't available in webkit.

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.

errorception 's founder gave a nice talk on all the various techniques here http://errorception.com/slides/jsfoo#summary-so-far

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.

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?

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

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

Is this basically what Proxino does? https://www.proxino.com/

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

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 :-(.

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.

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

Good luck!

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?

They list that they support source maps in the features:

http://www.html5rocks.com/en/tutorials/developertools/source...

Yes, I'm wondering if there's a way to keep the source maps private.

For what reason? It's not as if minifying your assets is a reliable form of security.

Exactly. Anyone determined enough can essentially reconstruct your non-minified code from the minified version.

"essentially reconstruct"? That's generous language. You have to somehow determine the use of all variables and functions and what proper names for them would be. Outside of DOM calls, the logic and application layer is close to incomprehensible. See also the javascript of any large webapp.

> You have to somehow determine the use of all variables and functions and what proper names for them would be.

True, but in the mean time you can amuse yourself with hilarious variable names:

http://media.admob.com/gmsg.js => http://paste.ubuntu.com/1205328/

Or you can be lucky enough to find unobfuscated versions anyway, regardless of source maps:

http://cdn.optimizely.com/js/673.js

.. well, it was working yesterday.

Milk, turnip, knife? That's funny. I might start coding like that by default.

I've seen the javascript of large webapps. That's why I said determined. You could reverse-engineer even the craziest logic if you wanted.

Not for the security of the application, but to protect intellectual property. It's much less tempting to "borrow" snippets of code when it's been minified.

There are two ways of associating a sourcemap with a file in the spec: 1) http header and 2) //@ sourceMappingURL comment in the destination file. You could expose the HTTP header only to to Rescue.js IPs, or alternatively they could conceivably provide an interface to make the map associations within the admin panel.

Ah. An interface in the admin panel sounds best, but that would probably add steps to a deployment process...

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.

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.

It isnt, the source maps are what is used to get it back to an unminified state

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.

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!

Maybe the source is not special or unique, but not everyone wants to give away their work. Eg you just spent 6 months developing a product feature and by coincidence your competitor also launches the same feature 2 weeks later :|

Of course minified code is also usable, however it makes things just that little bit more difficult for rip off artists.

I'm all for free and open software, but some aren't, and they're free to feel that way.

I don't think I have any tricks clever enough to help anyone who can easily read minified code :) I only want to prevent simple theft from copy/pasting of source code.

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

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

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

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.

Is this like http://errorception.com/ ?

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

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

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

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.

As other commenters have mentioned, Source Maps are the solution to this problem in general. The main reason we don't yet allow signup to RescueJS is that "create a source map" is currently beyond the state of the art for web frameworks. You can't "just" do it.

Over the weekend we spent a few hours trying to hook source maps into the asset pipeline for Rails based on https://github.com/sstephenson/sprockets/pull/311 and upgrading the 'uglifier' rubygem to work with UglifyJS2. We didn't manage to get it quite working within the time limit, but we'll try and push our work-in-progress upstream to get this ball moving again.

Reply on news.ycombinator.com