Skip to main content

Suppressing and Logging JavaScript Error messages

When it comes time to run your fancy AJAX site on production, you may find that there will occasionally be minor JavaScript errors (possibly from 3rd party sites, never your own of course) which will not only prevent your scripts from running but may also pop up some warning boxes on the end users' systems (especially if your target audience is made up of web developers who have "Disable JavaScript Debugging" unchecked).

Even if the user does not have debugging turned on, they may still see the error symbol in the status bar (and this does not exactly put their fears at ease, especially if they are trying to make a cash transaction).

Fortunately, you can suppress these error messages by using the following JavaScript code

function noError(){return true;}
window.onerror = noError;

Essentially what this does is catch any JavaScript errors and passes them to a null function. You should probably wrap this in a conditional which will only run on production and staging because as you are developing you will want to see these errors to prevent them from happening in the first place (i.e.
<%if ENV['RAILS_ENV'] == 'production' || ENV['RAILS_ENV'] == 'staging' %>
<script type="text/javascript">
function noError(){return true;}
window.onerror = noError;

</script/>
<% end %>
).

window.onerror, as it happens, can also pass in some useful variables if you want to log them somehow. These are the error message, the url and the linenumber.


function alertError(message, url, linenumber){
alert(message + " " + url + " " + linenumber)
return true;
}
window.onerror = alertError;


However, what you probably really want to do is log it to your server via AJAX as opposed to alerting the error message to the user (using jQuery below).

function logError(message, url, linenumber){
$.ajax({
type: 'GET',
url: '/javascript_error',
data: {message:message, url:url, linenumber:linenumber},
dataType: 'json'
});
return true;
}
window.onerror = logError;


On the server side, create a small function which will take in these parameters and log them along with the user's remote address and user agent ( request.remote_addr and request.user_agent in Rails).

There are some browser differences (and inconsistencies) with this however. For a start, while Firefox will give you the url of the JavaScript file in which the error occurs, Internet Explorer will only give you the url of the page that is rendered in the browser (i.e. what is in the location box). Safari does not seem to support these at all (Safari will suppress the error, but not run the alertError function) and IE in debug mode behaves the same as Safari.

Comments

Dumitru Glavan said…
It's a bit more complex to log the clientside errors, supporting all the major browsers and mobile devices. We built http://jslogger.com to take care about that. It's also possible to log the backend errors with the NodeJS library. Worth to give it a try.

Popular posts from this blog

Master of my domain

Hi All, I just got myself a new domain ( http://www.skuunk.com ). The reason is that Blogspot.com is offering cheap domain via GoDaddy.com and I thought after having this nickname for nigh on 10 years it was time to buy the domain before someone else did (also I read somewhere that using blogspot.com in your domain is the equivalent of an aol.com or hotmail.com email address...shudder...). Of course I forgot that I would have to re-register my blog everywhere (which is taking ages) not to mention set up all my stats stuff again. *sigh*. It's a blogger's life... In any case, don't forget to bookmark the new address and to vote me up on Technorati !

Speeding up RSpec

So today I have been looking into getting our enormous battery of tests to run faster. I have yet to find anything that works for Cucumber, but I did find an interesting way to speed up RSpec which is detailed here. https://makandracards.com/makandra/950-speed-up-rspec-by-deferring-garbage-collection Basically, it seems that by not collecting garbage too frequently, you can make your tests run much faster (at the expense of memory management of course). We observed a 30% reduction in the time it takes to run an RSpec test suite. I did try to implement this on Cucumber, however because we need to store much more in memory to set up and tear down our objects, it meant that I kept running out of memory when I wasn't using the default Garbage Collection and the tests took even longer (so, buyer beware). I suppose if you had a small set of features though you might see some benefit.

Responsive Web Design

I wanted to go over Responsive Web Design using CSS. In the old days of web development, we had to code to common screen sizes (i.e. 800 X 600, 1024 X 768) and we patiently waited for people to upgrade their computers to have a decent amount of screen real estate so we could design things the way we really wanted. We also took on semi stretchy web layouts etc to expand and contract appropriately. Then about 2 or 3 years ago, Apple released this little device called an iPhone with a 320 X 480 resolution which took the world by storm and suddenly a lot of people were viewing your website on a tiny screen again... Anyways, as it can be difficult to design a site which looks good on 320 X 480 AND 1680 X 1050, we need to come up with some kind of solution. One way is to sniff the client and then use an appropriate stylesheet, but then you are mixing CSS with either JavaScript or server side programming and also potentially maintaining a list of appropriate clients and stylesheets. Also, you