Wednesday, March 14, 2012

Virtues of Error Messages

In my role as a consultant, I frequently find myself picking up unfamiliar technology. Sometimes it's a new framework that a client happens to be using. Frequently it's an application or code base I'm evaluating on behalf of a client. Sometimes it's a bake-off between products my client is considering to solve some purpose.

One of the most valuable things with getting up and running with these unfamiliar technologies is this:

The error messages.

With an unfamiliar technology there's a good chance I'm going to do something wrong when I first get started. Usually it's something like a missing dependency, or a configuration that needs to be set up. These aren't major problems, but they sure can seem mysterious. After all, I'm often working with someone else's application; it's not exactly the same as doing a "hello world" on [insert framework of choice here].

This is where error messages come in. A good error message will point toward what's wrong. For example, "missing config file in app/config/database.cfg" is a good error message. A bad error message will at least tell you that something is wrong. The worst is when there is NO error message.

For example, I was starting a grails app the other day, and here's what happened:

Running Grails application..

And then the command prompt.

No error message. No indication there was something wrong. Just.... nothing. Oh I eventually figured out that there was a problem (no app running, nothing listening on any new ports), and then I figured out what the problem was. But having an error message - even a bad one! - would have gone a long way toward figuring out what happens.

So please, if you're writing software, make sure you write in an error message. It doesn't even have to be good. Just don't ever fail silently. Your fellow software engineers will thank you.

No comments:

Post a Comment