Doing Something Else With The Error
Although we've now replaced the browsers handling of the error with our own the alert message really doesn't help much. It is still awkward, intrusive, lacks any helpful information, and leaves the visitor sitting on a broken page.
Failing Gracefully With an Error Document
My favorite way to deal with an incapacitated page is to redirect the visitor to a friendly error message reminiscent of a 404 response. [View Redirect Example] This new document gives you ample room to explain what has happened. In your message it may be a good idea to explain the following:
- If the document is information based then provide the visitor with alternate sources for the information found on the page with the error. Perhaps there is a text only or printer friendly version that resides elsewhere on the site.
- If the document contains more of an experimental interactive piece, or is merely navigation to some other piece of information then say so. The visitor doesn't need to be worried that they're missing something if they're not.
- Explain the technology used and why. If the script was written to follow current web standards as defined by the W3C recommendations mention that also.
- Explain what browsers the document is known to work in and provide links.
Finding and Fixing The Error
While one should always code carefully and do rigorous testing it is nearly impossible to view a page on every existing browser/os platform before you release it to the public. So one can expect errors of some sort to occur. We just have to be alerted to the fact that someone encountered an error so that we know to fix it. This is the most difficult part of maintaining a web site because visitors never take the time to email you about problems with your site unless your site is the only place on the web to do what they need to do. (e.g. their online banking web site).
Your results may vary depending on what format your server logs requests in and what information different browsers report.
While up front browser detection/redirection is a useful technique it is not always accurate. You can't test every User Agent in existence so a few browsers that might work get blocked and a few that don't get in. Using the onerror event to either suppress or react to errors provides an additional layer of protection.
The window.onerror event does not have to be the last line of defense in your scripting arsenal. When writing scripts that are intended only for use by standards compliant browsers it can also act as a poor man's exception handling and be your first line of defense.
The above example shows a script that one would expect to cause errors in any User Agent that doesn't support the current standards. Instead if filling the document with a bunch of if statements checking each property before we use it the script just goes ahead and tries it. Failing to execute the script sends the visitor to a page much like they might if their browser support was checked ahead of time. [View Exception Example]