We need better error messages

Email.Email weblog link
Blog this.Blog this
Eric M. Burke

Eric M. Burke
Apr. 06, 2003 07:26 PM

Atom feed for this author. RSS 1.0 feed for this author. RSS 2.0 feed for this author.

The other day I helped a fellow developer track down a problem in some server-side code. He probably spent a few hours working on the problem, and I helped him for at least 30 additional minutes before we finally figured it out. The basic problem was that we were attempting to insert a record into a database and one of our fields was too large for the column. We got some obscure database error...I don't remember the specifics, but it was something like:

ERROR: Data exceeds column size.

Of course the root problem was trivial, but these things can be quite tedious to track down when you have complex SQL statements hitting multiple tables with lots of columns. We resorted to lots of logging statements along with a laborious process of manually validating that each column was big enough to hold its data. We eventually determined that our username column was only defined as a 3-character field, which caused problems for anyone using a username longer than 3 characters. (we were using a dummy user called 'sys' for testing so we didn't see the problem until a real user signed on).

Here's my beef. Why didn't the original programmer spend a few minutes improving the error message? For example:

ERROR: Data for 'username' column exceeds column size of 3 characters.


This would have taken the original programmer a few seconds, and would have saved us several hours of debugging time. I'm sure thousands of other programmers have encountered this exact same problem due to this specific error message.

While I'm using this particular database error message for an example, I can state from experience that JNDI and CLASSPATH problems are two other particularly difficult technologies when it comes to diagnosing problems. Wouldn't it be great if whenever you got a NoClassDefFoundError, the class loader dumped a list of places it looked for your class?

Anyway, the point is simple. People who write framework software should spend more time on useful error messages that show people why the error occurred and give a clue as to how to fix it. This would save millions of dollars in wasted productivity each year. (OK, I'm just making up that number, but it wouldn't surprise me)

Eric M. Burke is an O'Reilly author and a principal software engineer with Object Computing, Inc. in St. Louis, MO.