Users of Mozilla Firefox may have come across the following instance:
uncaught exception: [Exception… “Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]” nsresult: “0x80040111 (NS_ERROR_NOT_AVAILABLE)” location: “JS frame :: http://localhost:3000/ajax2.html :: anonymous :: line 21” data: no]
The same exception, in case of Google Chrome, is somewhat like:
Uncaught Error: INVALID_STATE_ERR: DOM Exception 11
This instance arises when the system runs into a ‘bug’ while accessing the ‘status’ of the complete handler, and the ajax request timed out. This results in a browser exception. The instance is easily reproducible, utilizing jQuery. The only way to work around this browser peculiarity is to examine the test status that jQuery provides, before trying to access the xhr.status. And possibly it is the only way to check the ajax status without the risk of running into an exception again. For example, this can be achieved by the following code:
complete: function( xhr, text_status )
if ( text_status == ‘timeout’ )
alert( ‘TIMED OUT’ );
alert( xhr.status );
According to the W3 working draft, for XMLHttpRequest object, when the ReadyState of an XMLHttpRequest is 3 or 4 then the status and statusText is available. After that, these values can determine if the request was successfully processed or not. Even though more often than not, the status is 200 when the request is successful, and 404 when the request fails. However, this does not cover the case when the network connection link fails while the XMLHttpRequest is either sent, or is still being sent.
Different browsers have different values of readyState, status and statusText to deal with different cases of browser exceptions and peculiarities. For this particular browser peculiarity, in a Firefox installation running on a Windows XP platform, both the status as well as the statusText are shown as ‘exception thrown’. Internet Explorer, running on the same platform, shows a status of 12029, and unknown as statusText. For Opera, the statusText remains empty, while status is a ‘0’. Safari shows both fields as unknown. Only the readyState value remains constant in all these cases, that is, 4. End users can create their own tests by creating a page which sends an AJAX request on the click of a button. The page is loaded, the connection is severed, and then the link which initiates the request is clicked. After this, the readyState, status and the statusText are recorded, or in case any exception occurs, it is observed. Even though XMLHttpRequests rarely fail due to network failure, it is always worth it to be able to detect the failure and handle the matter properly with the client side server. The best way, is obviously to display an appropriate message on your page in case any such browser peculiarities occur. In case of a link failure, it is obvious that the error message display will not be able to display any images in case the error message widget has an image which needs to be accessed from the server. However, this issue can be resolved if the error message image is pre-loaded during the page-load. That way, the error message widget can display the error code along with the pre-loaded image. Some websites, or browsers, are instructed to redirect the user to another page,in case of any such error in network connection. However, this must be avoided as it is unlikely that the user will be able to access the redirected page in case of a network connection failure.
Bounceweb provides 24/7 support for Ajax hosting | Ajax webhosting!
Leave a Reply
You must be logged in to post a comment.