Vishful thinking…

Error handling for the ESRI JS API

Posted in ArcGIS, ESRI, javascript by viswaug on November 9, 2008

Writing good software means handling errors properly so that the user can notified of the error and appropriate action can be taken in response to the error. I was looking to doing the same for when I was using the ‘QueryTask‘ and other tasks in the JS API that make ajax requests back to ArcGIS Server. The ‘execute(parameters, callback?)’ method on the QueryTask provides a way to specify a function that will handle the results from the server. The call back function is only called when the ajax request is successful. But what if the ajax request failed? How would you handle that? If you are using FireFox with the FireBug add-on, then you would notice that an error message gets logged to the console in FireBug. In my application, I block access to the map when the QueryTask is being executed and until a successful response is received from the server. But I needed a way to be notified when the QueryTask failed so that I could unblock the map and inform the user of the error. After some sleuthing around the JS API, I was able to handle the errors that happen in the JS API. The Dojo library includes a publish & subscribe event system which allows for anonymous event publication and subscription. Using this functionality any piece of code in JavaScript can publish an event with a specific name and all interested parties can subscribe to the event using the event name. And subsequently unsubscribe when not needed.

dojo.publish(Topic Name [string], Arguments to Pass to Subscribed Function [array])

handle = dojo.subscribe(Topic Name [string], Context of Linked Method [string or null], Linked Method [string or function])

dojo.unsubscribe(Handle [handle object])

Well, the JS API leverages this and publishes an event named ‘esri.Error‘ whenever an error happens during an ajax request. So, you can subscribe to the ‘esri.Error’ event that is published by the JS API right before calling execute on the QueryTask and unsubscribe when the results are successfully returned or if an error occurred. This should suffice for most cases but if you are a stickler, you will soon realize that if you execute many QueryTasks simultaneously the error subscription only lets you know that an error occurred and the error message. It however does not let you know which one of the QueryTasks failed. Another way the error can be handled is by temporarily overwriting the ‘‘ function and resetting it after the request has returned successfully or with an error. But this way also has similar drawbacks. The best solution to the problem would be for the execute method on the QueryTask to take an error handler function as another parameter.