In my last entry, I added a quote in my book review of “Clean Code,” about handing exceptions with “grace and style.” Not all programs handle errors well, including best-selling and useful programs produced by companies known for products of the highest quality.

 

I am currently using ArcGIS Online, in concert with Collector for ArcGIS, both products of Environmental Research Systems Institute (ESRI). You make a complex map, which includes a background map of aerial imagery and load the map in into a mobile device for the field data collection of points, lines, and polygons. The map is set up to work in the field remotely, without connections to the Internet. All the data must be stored on the mobile device and it is a large amount of data.

 

The system failure is loading the map into the mobile device. It takes about 15 minutes, and it displays a moving circle showing progress. But then it fails. A message saying “download failed” appears, for a mere second or two only, and Collector for ArcGIS returns to its quiescent state, with no indication that what you tried did not work. There is no indication you even tried to load the map. 

 

There are two problems with this:  1) You never see the error message unless you stare at the screen for 15 minutes, waiting patiently; 2) even if you see the error message, the “download failed” does not give you a clue about what went wrong. This is not handling an exception with “grace and style.” 

 

After numerous retries, the data transfers works. By reducing the size of the map and trying again, you can make it fit. An error message about insufficient memory in the mobile device would have been helpful. But I have no way of knowing what really went wrong.

 

Yet, the program is useful, powerful, and works well. ESRI has a huge suite of fine products, and their customer support is exceptional.  

 

No program is perfect.  But ESRI could have provided a better error message and kept the error message visible until the user acknowledged reading it.