Chapter 8. Error messages

Nikolay (unDEFER) Krivchenkov


One of the major components of the any complex application's convenient interface are messages for user. Among them - error messages. And unfortunately they often appear not clear.

Often developers leave error messages in a kind clear only for them. Probably in hope that the user never will see them.

Error messages like: "an error №XXXX" are especially terrible.

Besides simply not clear error messages exists at least two examples of typical error processing methods which do not give the sufficient information on it:

  1. If exists three conditions (a, b and c) which should be true simultaneously, there is a big temptation to use the following processing code:

    if ( ! (a && b && c) ) { /*Error*/ ... }

    Merging three various variants of an error in one. As a result the user cannot know on an error message, what exactly not so. And if he/she isn't the developer also cannot add additional checks for this aim. So he/she need to choose the three variants of input data to check all possible variants.

  2. If a() function calls b() function which cause an error, often the error message is written only in one of these functions. In any case thus there is not complete error message. For example, "The program error when document opening" without specify what kind of error occurs, or "Unexpected symbols when parse document" without specify why there is necessary to open this document.

Anyway incomplete error messages lead to huge losses of time of the user. I personally had very memorable case when because of a small error in syntax of a mysql file I have lost half day on its searches. The mysql for certain "knew" where an error, but has given me its much more general description.

I very want, each developer which had read this text, has remembered: any trifle in the program, leading to loss by the user more than 5 minutes of time absolutely without advancement as a result, are an interface bug and it demands correction. Users in turn should inform about such losses of time as about bugs.

Ideally the system should give as much as possible full information on any error and ways of its elimination. Besides this, the information should be accessible without access to Internet network or any similar.

Naturally all these thoughts should become an integral part of unDE concept. Logo