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

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.
9:00 AM
Post a Comment

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 !
Post a Comment
Read more

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.
2 comments
Read more

Elixir - destructuring, function overloading and pattern matching

Why am I covering 3 Elixir topics at once? Well, perhaps it is to show you how the three are used together. Individually, any of these 3 are interesting, but combined, they provide you with a means of essentially getting rid of conditionals and spaghetti logic. Consider the following function. def greet_beatle(person) do case person.first_name do "John" -> "Hello John." "Paul" -> "Good day Paul." "George" -> "Georgie boy, how you doing?" "Ringo" -> "What a drummer!" _-> "You are not a Beatle, #{person.first_name}" end end Yeah, it basically works, but there is a big old case statement in there. If you wanted to do something more as well depending on the person, you could easily end up with some spaghetti logic. Let's see how we can simplify this a little. def greet_beatle(%{first_name: first_name}) do case first_name d
Post a Comment
Read more