Poorly-Written Error Messages Trump Crashes

The quality of an application’s error messages comes under close scrutiny during an expert usability review. Well-written error messages inform users about the steps they should take next to move on with their task. Many poorly-written error messages simply report the internal state of the application in the unrealistic hope that users will understand the problem and therefore be able to correct it. However, detecting that an error has occurred and presenting some warning to users is far better than simply crashing.

As operating system and application quality improves, outright crashes happen less often. Unfortunately, applications do still crash without warning and these are the most challenging error scenarios to diagnose. I recently had to diagnose such a scenario when connecting the MySQL relational database with the SPSS statistical analysis package. SPSS was able to import data from every table except three. Importing data from these three tables caused SPSS to crash with no preceding error message. Even looking at the names of the columns in the table crashed SPSS.

Systematically working through what could be causing SPSS to crash when importing data from just three tables, I asked questions like these:

  • Did the tables contain too much data for SPSS to handle? No. Other tables with many more rows imported successfully.
  • Did the tables use MySQL data types that the MySQL/SPSS driver couldn’t handle? No. All of the data types in the crashing tables were imported successfully in the other tables.

Nothing obvious could have been causing SPSS to crash. After much head scratching I noticed a pattern in the way I had named the tables. It turned out that SPSS couldn’t import data from tables with a name longer than sixteen characters. I had initially dismissed this as such an unlikely cause for two reasons. Firstly, because the days of limiting names to such a small number of characters to save storage are long gone; and secondly, because tables with names of similar length imported successfully. For example, after counting the number of characters in the names of the tables, I noticed that one table that imported successfully had a sixteen character long name and another that crashed SPSS had a seventeen character long name. I had missed this difference because SPSS presented the table names in a proportionally-spaced font which made the two table names look almost identical in length.

Even though I believe it was unnecessary for the SPSS developers to limit the length of table names to such a small number of characters, checking for the maximum allowed table name length and informing users of the limitation would have been a far better approach than crashing. Also, if the length of table names is an issue, then displaying table names in a non-proportionally-spaced font would help users identify lengthy table names.

blog comments powered by Disqus