Error message FAIL
The other day while on a bus in Brisbane, I witnessed a classic error message FAIL:
On a more serious note, error handling and the display of error messages in software development is an often discussed usability topic. Errors occur for all sorts of reasons – user-generated, hardware failures, invalid data, and of course software bugs. But how much do you let the end-user know that the software has failed? Well, I believe it depends on the type of error, the impact of the error and who your audience is.
Clearly in this case letting the end-user (i.e. the general population driving by) know that the modem had failed was not useful at all. What would an end-user be able to do with that knowledge? Nothing. They can’t fix it nor would they care to. Showing them that message is pointless and makes the manufacturers of the mobile street display look stupid. SOMEONE ought to know about the failure but in this case that someone is certainly not the end-user.
Another concern with display error messages such as the one I witnessed the other day is that it gives those malicious souls out there who thrive on breaking other people’s software a better idea of what will make the software break.
Personally, I’m a fan of generating more than one type of error message upon software failure and audience. If the end-user is likely to be the general population (i.e. website users), then you should look at what caused the software to fail. If you’re allowing users to generate errors by entering invalid data into a form, then you should probably let the user know that they entered some invalid data and that they should try entering something valid next time. However, if you’ve coded restrictions into the software so that they should never be able to enter invalid data but somehow they do anyway, then you may be a victim of a hacker’s attack. In this case, you do not want to admit that they have almost just broken your site because if you do you’ll only be encouraging them to try again and you may have just given them the extra information they needed to totally own your site. Instead, the message you display to the end-user should be a friendly and generic/vague one, something along the lines of ‘Oops! Your request returned no results. Please try again later or contact support.’. That way, the hacker will be none the wiser or at least they won’t think that their last input came so close to pulling your site down. The same error should be logged somewhere on the system (event log, log file, database error log…) with a much more specific error message. If it’s a critical error then perhaps it should even be emailed or sms’ed to an administrator automatically.
I guess the moral of the story is that it really doesn’t matter that you’ve handled all the potential errors in your code. What really matters is how you’ve handled them, in particular, who you’ve alerted and what information you’ve given them. Telling the world that the last input caused an integer overflow is probably not the best way to keep hackers out and users in! If you’re a developer, think carefully about every line of code you write and if that line can raise an exception then make sure you know what to do when it happens.
