Error collection policies in Software

 

The program with Error = 0 does not exist. How can I collect and process errors in the program? How can we make better use of error information collection and feedback to assist program debugging? How can users report more valuable questions after the product is released? These problems will be covered in this article. Recently, I have made some summary and thoughts on the error processor in my project. I hope this article will help you.

At present, according to my personal understanding, there are several main methods of collecting errors and feedback in software:

Method 1: Use common information output statements.

For console programs, you can use the printf statement or std: cout to print out the error information. For MFC programs, you can use the TRACE macro to output the error information to the output window, alternatively, you can use the MessageBox pop-up box to notify you of the error message.

These processing policies are often targeted at "interactive" code segments, which can provide real-time feedback of error information for users to process in real time to avoid larger errors.

Method 2: Use error logs

Idea: output all error messages in the program to the error log file, which has the following benefits:

1. After the program is released, the customer can directly send the error log to the programmer after encountering problems during use, which greatly facilitates problem locating and cause analysis.

2. it is easy to debug multiple threads or complex programs involving network communication, because in such a program, it is very inconvenient to set the breakpoint debugging method. Once paused at the breakpoint, it is often caused by thread exceptions or network connection disconnection, which greatly affects the debugging efficiency. If you print the error information to a file, the error description is more detailed, which can greatly improve the debugging efficiency.

3. It is easy for programs to perform large-scale performance tests. For example, in the C/S mode, 100 clients can access the server and use this error collection policy to conveniently analyze the error log file to speculate on the system performance.

The following is a question: Many software designs have an application layer module similar to the TCP/IP protocol. This module is generally a layer of direct interaction with the client, it isolates the coupling between the core code module and the client. Then, for such a hierarchical design scheme, how does the bottom-layer error information pass to the top-layer? Each layer provides an interface for obtaining error information? In this way, the overhead is too large and it is often not ideal. What should we do?

I think there are mainly two processing strategies, namely, the third and fourth strategies for error collection and feedback that I will introduce:

Method 3: C ++ exception Mechanism

The C ++ Exception Handling Mechanism is a powerful and flexible tool used to effectively handle running errors. It provides more flexibility, security, and stability, overcome the problems brought about by traditional methods.

The following keywords are used to throw and handle exceptions: try, throw, and catch.

Throws and captures exceptions. These policies are extremely convenient for C ++ to handle exceptions. They can be caught and processed at the bottom layer.

To be honest, the C ++ exception mechanism is indeed a good strategy for handling errors and exceptions. If you need to use this mechanism, you need to consider it from the software architecture and design, once the software structure and code are written to a certain extent, introducing the exception mechanism will be difficult to achieve good results. In fact, it is not easy to make good use of the c ++ exception mechanism. Especially when there are a large number of new people in the project team, the cost of use is quite high.

Many C ++ books have introduced the C ++ exception mechanism. I will not go into details here. This blog also provides an example code for getting started with the C ++ exception mechanism, for more information, see http://ticktick.blog.51cto.com/823160/191881.

Method 4: GetLastError Mode

People who often develop windows programs should understand that windows programs have an API: GetLastError, which actually represents an error collection and processing mechanism.

When a Windows function detects an error, it uses a mechanism called thread-localstorage. When a function returns, its return value is flase, which indicates that an error has occurred. To determine what the error is, call the GetLastError function to obtain it: This function only returns the 32-bit error code of the thread.

The WinError. h header file contains a list of error codes defined by Microsoft.

When Windows functions fail to run, call the GetLastError function immediately. If another Windows function is called, its value may be rewritten.

Visual studio also has a small utility called Error Lookup.

If an error is found in the written application, you may want to display the text description of the error to the user. Windows provides a function to convert the error code into its text description. This function is called FormatMessage.

The above is the introduction of the GetLastError mode. You can simply think of it as a mode in which a global variable can be used to store 32-bit error codes. Once a Windows function fails to run, assign the error code to the global variable. When GetLastError is called, the error code is returned for external analysis.

In fact, we can also implement this GetLastError mode error collection mechanism to collect the latest error information in the entire program for the upper layer to call and query in a timely manner, define your own error code and description string, so how can we better implement a similar error collection feedback mechanism? How can we make it more portable, robust, and supports multithreading?) and easy to add new error code and information? I will introduce my thoughts and designs in the following articles.

The above are my thoughts and conclusions on the error collection strategies in the software. I hope to help you and welcome your comments and suggestions.

 

 

This article from the "three shadows" blog, please be sure to keep this source http://ticktick.blog.51cto.com/823160/213580