This is a shameless plug for Eric Schrock’s blog post on the same subject.
When we write software, one of the things we usually strive for is to
make the user experience friendly. A large part of this is making the
software easy to use, but a bigger part is making it fail nicely.
Although it’s relatively easy to write software that works when
everything goes well, but it’s harder to make software that does the
right thing in the case of failure. This is one of my personal
IT crusades because I’ve dealt with way to much software that
provides near meaningless error messages, or even worse it completely
fails with dreaded segmentation violations, NullPointerExceptions,
etc. due to poor error checking.
Eric Schrock has some good ideas on what the right thing is and
suggests that “[w]hen choosing to display an error message, you should
always take the following into account:
“An error message must clearly identify the source of the problem in a
way that that the user can understand.“An error message must suggest what the user can do to fix the problem.”
I like these principles; they are simple, concise, and I can do
nothing but agree with both of them based on my experience as a user,
a system administrator, and a developer. He goes into more detail in
his blog post, and I suggest that anyone who writes any code, be it a
small shell script, or a large application read it. We can all do our
own part to improve the situation for our users and raise the bar for
all software.
Next post, I’ll talk about some of the things that I’ve found help out
a lot in Java programming (one of the comments on Eric’s blog post
goes into one such item that happens to be a pet peeve of mine). For
now, I just have to say that I think the people working on the Spring Framework do a great job. Rock on, folks!
(note: this was originally published 2007–02–24 16:14:06 at blogs.opennms.org; links have been updated with current pointers where possible)
