Take the 2-minute tour ×

I was wondering what the general consensus on error messages was. How detailed should they be?

I've worked on projects where there was a different error message for entering a number that was too big, too small, had a decimal, was a string, etc. That was quite nice for the user as they knew exactly where things went wrong, but the error handling code started to rival the actual business logic in size, and started to develop some of its own bugs.

On the other side I've worked on a project where you'd get very generic errors such as


Which needless to say was almost entirely useless as reason 3 turned out to mean a link error.

So where is the middle ground? How do I know if I've added descriptive enough error messages? How do I know if the user will be able to understand where they've gone wrong?

share|improve this question
add comment

7 Answers

up vote 11 down vote accepted

There are two possible target audiences for an error message, the user, and the developer.

One should generally have the message target the user.

o what is the cause of the problem.
o why the program can't work around the problem
o what the user can do to work around the problem.
o how to report the problem.

If the problem is to be reported, the report should include as much program context information as possible.

o module name
o function name
o line number
o variables of interest in the general area of the problem
o maybe even a core dump.

Target the correct audience.

share|improve this answer
"how to report the problem" - or better, assurance that the problem has already been reported –  Chris Noe Dec 31 '08 at 16:43
+1 on that. You don't want to provide unnecessary clicking. I can't imagine many users who would be upset about it. –  Jonta Jan 23 '09 at 13:50
add comment

You should communicate what happened, and what the user's options are, in as few words as possible. The longer the error message is, the less likely the user is to read it. By the same token, short error messages are cryptic and useless. There's a sweet spot in terms of length, and it's different for every situation.

Too short:

Invalid input.

Too long:

Please enter a correctly formatted IP address, such as An IP address is a number used to identify your computer on a network.

Just right:

Please enter a valid IP address.

As far as code bloat is concerned, if a little extra code will prevent a user from calling support or getting frustraited, then it's a good investment.

share|improve this answer
"Just right" might be too less. I would expect info about what the user has entered AND a sample what he should enter. Something like "Don't understand '192,168,02'. Please enter a valid IP address (e.g." –  stefan bachert May 2 '12 at 11:34
add comment

There are two types of error messages: Those that will be seen by the user and those that'll be seen by the programmer.

"How do I know if the user will be able to understand where they've gone wrong?" I'm assuming that those messages are only going to be seen by the user, and not a very technical one, and COMPILE FAILED REASON 3 is not a typical end-user error message. It's something that the programmer will see(the user doesn't usually compile things).

So, if it's the user that'll see it:

  1. Provide a short "This is an error message"("Ops! Something went wrong!", etc.)
  2. Provide a small generic description of the error ("The site you're trying to connect to seems to be unavailable"/"You don't seem to have enough permissions to perform the XYZ task"/etc.)
  3. Add a "Details>>" button, in case your user happens to understand computers well, including detailed information(exception stack trace, error code, etc.)

Finally, provide some simple and understandable commands for the user ("Try again", "Cancel", etc.)

share|improve this answer
The product for the cryptic error message was a compiler, so in this case yes, they will be compiling things. But point well taken. –  ReaperUnreal Dec 31 '08 at 16:27
add comment

The real question about error messages is if they should even be displayed. A lot of error messages are presented to a user but there is NO WAY for them to correct them.

As long as there is a way to correct the error then give enough information to the user that will allow them to correct it on their own. If they are not able to correct it on their own is there any reason to tell them the technical reason for the crash? No just log it to a file for troubleshooting later.

share|improve this answer
I hate when programs crash and I have to go find a log file for an error message to Google. Even if it's not necessarily fixable, giving me something I can Google might let me work around it much easier. –  Andrew Coleson Dec 31 '08 at 16:59
If it's not fixable how is google going to help you. If there is a way to correct the problem google will help but should not be required if you explain how to properly correct it in the first place. –  Adam Peck Dec 31 '08 at 20:59
add comment

As detailed as they need to be ;)

I know it sounds like a smart ass answer but so much of this depends on your target audience and the type of error. For errors caused by invalid user entry, you could show them what constitutes a valid entry. For errors that the user can't control, a generic "we're working on it" type message might do.

I agree with Jon B's comments regarding length as well.

share|improve this answer
add comment

Error messages should be detailed, but clear. This can be achieved by combining error messages from multiple levels:

Failed to save the image
Permission denied: /foo.jpg

Here we have two levels. There can be more. First we tell the big picture and then we tell the details. The order is such that first we have the part understood by most and then the part less people understand, but both can still be visible.

Additionally there could be a fix suggestion.

share|improve this answer
add comment

I would err on the side of more detail, but I think you answered your own question. To avoid the bloat in code then provide useful information in the code/error message but you can give more details in the documentation perhaps or with help files or FAQ.

having too little information is worse in my opinion.

If you are using a language with rich introspection or other capabilities, a log witht he line that failed a check would be useful. The user can then forward to tech support or otherwise get detailed information and this is not additional code bloat, but using your own code to provide information.

share|improve this answer
add comment

Your Answer


