What are the best practices for JavaScript error handling?

Question

An immensely interesting set of slides on Enterprise JavaScript Error Handling can be found at https://web.archive.org/web/20140126104824/http://www.devhands.com/2008/10/javascript-error-handling-and-general-best-practices/

In short it summarizes:

1. Assume your code will fail
2. Log errors to the server
3. You, not the browser, handle errors
4. Identify where errors might occur
5. Throw your own errors
6. Distinguish fatal versus non-fatal errors
7. Provide a debug mode

The slides go into much more detail and most probably will give you some direction.

EDIT:

The presentation mentioned above can be found here: https://www.slideshare.net/nzakas/enterprise-javascript-error-handling-presentation

Nicholas Zakas of Yahoo! fame did a talk on Enterprise Error Handling (slides) at Ajax Experience 2008, in which he proposed something like this:

function log(sev,msg) {
    var img = new Image();
    img.src = "log.php?sev=" +
        encodeURIComponent(sev) +
        "&msg=" + encodeURIComponent(msg);
}

// usage
log(1, "Something bad happened.")

// Auto-log uncaught JS errors
window.onerror = function(msg, url, line) {
    log(1, msg);
    return true;
}

A year later, Nicholas Zakas posted an update on his blog which included a clever pattern to inject error handling code automatically on your production environment (using aspect-oriented programming).

When you start logging window.error calls, you're going to notice two things:

1. If your site is fairly complex, you're going to log a lot of errors
2. You'll be seeing a bunch of useless "window.error in undefined:0" messages

Reducing the torrent of log entries is as simple as testing for severity and/or a random number before logging to the server:

function log(sev,msg) {
    if (Math.random() > 0.1) return; // only log some errors

    var img = new Image();
    img.src = "log.php?sev=" +
        encodeURIComponent(sev) +
        "&msg=" + encodeURIComponent(msg);
}

Handling the useless window.error in undefined:0 errors depends on your site architecture, but can try identifying all Ajax calls and throwing an exception when something fails (possibly returning a stack trace using stacktrace.js).

IHMO, you should use error handling in javascript like you do in several other languages (AFAIK: Python, Java).

For better readability (and probably better performance, even though I am not sure it has a really big impact), you should use the try / catch block mostly on the following cases :

• The part of the code you want to wrap is a key part of the whole algorithm. If it fails, it could :

  • create errors on the next part of the codes (e.g. because a var is missing...)
  • make the page not look what expected (impact on content or css)
  • make the results appear strange to the user (impact on the code behavior)

• You know that the code you are writing is not compatible with every browser

• You planned that the code may fail (because there is no other way to check that it should work by if...then... blocks)
• And also when you want to debug without bothering the final user

Eventually, javascript experts may have other elements to give.

my 2 cents to the box,

Regards,

Max

In addition to the other answers: one important thing is to use context data available in JavaScript error objects and in the window.onerror function parameters.

Things like the stacktrace (errorObject.stack), the filename, the line number and the column number. Note that each browser has some differences...so do your best effort to get nice errors.

There can even be problems with the console object itself. I use a custom window.onerror function inspired by this one and a special function to trace any given standard error object inspired by this code.

Another good point is to include the version of your web application somewhere close to the stacktrace (for quick and safe copy and pasting). You may also show errors more aggressively (alert...) in development mode as developers will not constantly monitor the browser console and may not see some of the problems.

Also use avoid using throw 'My message', use throw new Error('My message'), you can even have custom errors, read this article.

Always add some context to the errors (the version, the id of the object, some custom message, ...) and also make sure you make a distinction between external errors (some external data or circumstance made your system fail) and internal errors/assertions (your own system messed up), read about 'Design by contract'.

Here is a guide.

Also think about using general error handling like interceptors your libs and frameworks:

• jQuery
• Angular 1.x and for http
• Angular 2.x
• Your new dope framework here ...