reptile7's JavaScript blog
Wednesday, October 21, 2009
 
Error Mechanics
Blog Entry #160

We continue today our discussion of HTML Goodies' "The onerror Event Handler" tutorial. In the tutorial's fourth paragraph, Joe passingly notes:
The way I've seen [onerror] used online is to tell the user what line the error came from. I guess that would be good for the developer, but I'm more concerned about the users.
Joe doesn't explain how to tell the user what line the error came from, so we'll do that, and analyze errors as objects more generally, in this post.

We previously detailed the Netscape-cum-W3C event model in Blog Entry #107. Let's recap briefly with the code snippet below:

function getCoordinates(e) {
window.alert("You clicked at (" + e.pageX + "," + e.pageY + ")."); }

document.onclick = getCoordinates;


An event-handling function can be registered with a particular object to listen for a particular type of event via an object.onevent = funcRef; assignment statement, which can precede or follow the event-handling function in the source. When such an event occurs, a corresponding event object is passed as a single parameter to the event-handling function, which can then probe and make use of the event object's properties. In the code above, the document.onclick = getCoordinates; statement coassociates the getCoordinates( ) function, click events, and the document object. When the user clicks anywhere in the document content area, a click event object is passed to getCoordinates( ) and given the identifier e. Subsequently, getCoordinates( ) displays the values of e's pageX/pageY properties - i.e., the click event's viewport coordinates - on an alert( ) box:

The getCoordinates( ) alert( ) box for a click event when using Firefox

Classical JavaScript equipped the event object with fifteen properties, only two of which could be used with an error object: target and type. Mozilla's DOM event Reference currently lists thirty event object properties, nine of which can be used with an error object: bubbles, cancelable, currentTarget, eventPhase, explicitOriginalTarget, originalTarget, target, timeStamp, and type. (More specifically, these are the properties that do not return undefined for an error object. This property list was determined via trial and error on my part - you won't find it in Mozilla's materials.)

The Netscape event model is applicable to the onerror event handler if onerror is paired with the image object/element:

<img id="myImage" src="whatever..gif" alt="" />

<script type="text/javascript">

document.getElementById("myImage").onerror = eventData;
function eventData(e) {
window.alert(e.cancelable); // displays true
window.alert(e.originalTarget); // displays [object HTMLImageElement]
window.alert(e.type); // displays error }

</script>


For an error event associated with the window object, however, a registered handler function is not parametrically passed an error object but rather three property-like pieces of information about the error in the following order:
arguments[0]: a message that briefly describes the error
arguments[1]: the full URL of the document that holds the script containing the error
arguments[2]: the document line number of the error

window.onerror = errorInfo;
function errorInfo(errorMessage, fileURL, lineNumber) {
document.write("This page throws a script error: " + errorMessage);
document.write("<br>The error appears in the file located at: " + fileURL);
document.write("<br>The error appears on line #: " + lineNumber); }


Getting back to "The onerror Event Handler", if we were to replace the redirect( ) script in the jserrorpage.html demo document with the preceding script, then the printed output when using Firefox would be:

This page throws a script error: document.wrte is not a function
The error appears in the file located at: http://www.htmlgoodies.com/legacy/beyond/javascript/jserrorpage.html
The error appears on line #: 33

At least with the Mozilla/Netscape family of browsers, the above errorInfo( ) function cannot be used to query the standard/non-standard* properties of the event object (forget for a moment that these properties are not all that useful for an error object). If we were to declare errorInfo( ) with a normal Error e parameter signature

function errorInfo(e) { ... }

then e, as arguments[0], would return the error message rather than [object Event].

*About half of Mozilla's event object properties can be considered "standard" in that they appear in the DOM Level 2 Events Specification.

Microsoft gives its window.onerror handler functions the same String errorMessage, String fileURL, int lineNumber parameter signature as did Netscape - check out the first example on the MSDN Library's onerror page. Microsoft's differing event model, which we outlined in Blog Entry #108, allows these functions to query properties of the event object. (Microsoft's event object properties are listed here; again, most of these properties will return undefined for an error object.) For example, if we replace the jserrorpage.html redirect( ) script with the script below

window.onerror = errorInfo;
function errorInfo(errorMessage, fileURL, lineNumber) {
document.write("This page throws a script error: " + errorMessage);
document.write("<br>The object that fired the error event was: " + event.srcElement); }


then the printed output when using MSIE is:

This page throws a script error: Object doesn't support this property or method
The object that fired the error event was: [object SCRIPT]

(Why [object SCRIPT] and not [object Window]? Dunno, but that's what I observe on my computer.)

N.B. For an error in an external myScript.js file, I find that Firefox and MSIE implement the fileURL and lineNumber parameters differently. For fileURL, Firefox returns the URL of the myScript.js file whereas MSIE returns the URL of the main document. Relatedly, for lineNumber, Firefox returns the error line number in the myScript.js file whereas MSIE returns the line number in the main document that references the myScript.js file, i.e., the line number of the <script type="text/javascript" src="myScript.js"> tag.

More than one error?

I said last time that I was interested in going through Netscape's "Example 3: Error handling function", which deserves its own entry, so we'll give it the full monty in the next post.

reptile7

Comments: Post a Comment

<< Home

Powered by Blogger

Actually, reptile7's JavaScript blog is powered by Café La Llave. ;-)