What are the best practices on the level of details in error messages?

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

COMPILE FAILED REASON 3

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?

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

One should generally have the message target the user.

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

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

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

Target the correct audience.