How to design error codes and error messages for the system

Author: Zhu Jinchan

Source: http://blog.csdn.net/clever101

A software system must be involved in a lot of error messages. For example, if a user performs an error, the software needs to return the error message to the user. So how do you design error codes and error messages? How the error message is returned. Here's a simple scenario to illustrate. For example, now we have a UI module (interface module) and a Algo module (algorithmic module) whose call relationship is as follows:

It's a bad programming habit to mention here that developers often pop up the error message box in the Algo module if there is an error inside the Algo module. This kind of habit is very bad, not good at where. Is that an algorithm module should minimize the intrusion of interface elements, if an algorithm module with interface elements, often limits the interface module portability, such as from one interface frame to another interface frame, from one operating system to another operating system. What's the right thing to do? is the algorithm module should return the error code to the interface module, the interface module through the error code to get error messages to pop-up error messages.

How to design the error code. Here we look at other people's practices, such as the Windows API. A number of functions in WINDOWSAPI are of type bool, and the return value of a function typically returns true to indicate success, and return false indicates failure. If the user needs more detailed error information, call a GetLastError function to get the error code, and then get the error message based on the error code.

Windows API This design is not good. It seems to me that it can solve the problem, but there are some drawbacks. One drawback is the need to use global variables to save the error code. As you know, global variables are used less and better. The disadvantage of two may be error in concurrency. For example, the same function is called at the same time in multiple threads, and the error code distinguishes between the several calls. There are solutions to this problem, but the solution increases the complexity of the system.

There is no better design. A better design is that the return value of the function no longer returns a bool, but rather returns an int type. The returned int value represents the error code, and the interface module gets the error message based on the error code. In this case, the error code simply needs to be a temporary variable.

Of course, there are some problems. For example, there are multiple algorithmic modules, how to avoid them using the same error code, such as 100. I envision a global dynamic increase in the error code starting value of the function to 100-bit interval. For example, the error code range of a algorithm module is 100 to 200,b algorithm module error code range is 201 to 300.

        after the design of the error code, we'll talk about the design of the error message. The design of error messages is also learned. First we need to be clear about who the error message should be. Some people may laugh, it is also used to ask, the error message is not oriented to software users. The answer is yes, but not complete. First, the error message is indeed for software users. Knowing this, we should have thought good error messages should not tell the user what the status quo is, but should also prompt the user how to solve the problem. such as "Data processing failure" is not a good error message, because this is only to tell the user what the status quo, such as "data processing failure, because the XXX input parameter input is not correct" better, because it reveals the solution, the user saw the understanding is due to the input of the wrong XXX parameter caused the processing failed. The next time he does it, he will notice to enter this parameter. In addition to the user-oriented error message, you should also face to whom. You should also target developers. Because after the error, the user can only put their own operations and see the error message to the technical support staff, and the technical support staff to the end of the error feedback to the developer. Therefore, the error message in detail is not a bad thing, the user does not understand the problem is not small, developers can rely on this information to help users solve the problem.