In the past, when developing c, c ++, and mfc programs, the error handling process was confusing. For historical reasons, when a windows program is developed using c, c ++, or mfc, many APIs handle errors by returning a value and specifying when the returned value indicates success, when does it mean a failure. To obtain more specific results, call GetLastError to obtain the error code (or the correct code, or call SetLastError to set the error code accordingly ). I personally think the disadvantage of this error handling method is that there is no unified standard to determine whether an api is successful or failed. For example, if 0 is returned, a function may be successful, A function indicates a failure, which can easily cause confusion. C # and Java programs have been written too much, and they are increasingly envious of the elegant Exception Handling Mechanism of the two ,.
In fact, c, c ++, and mfc also have their own exception handling mechanisms, but in my impression, this exception handling mechanism is far less popular than the method of judging the function return value. Although the exception handling mechanism will inevitably cause performance loss, I prefer this method because it provides a unified error handling interface. If you use c, c ++, and mfc to develop large applications and adopt a unified error handling method, this not only improves the maintainability of the code, but also makes the entire system more stable. Although C # and Java are increasingly widely used with their rich features, c and c ++ are still the first choice for development in many fields, it is good to be familiar with their exception handling mechanism. Last night (or this morning), my mind was so hot that I didn't turn off the lights because of the Champions League. So I took the opportunity to study the Exception Handling Mechanism in c and c ++, the main materials are Windows core programming and c ++ exception handle in msdn. I used to think that c ++ exception handling is only a simple extension of c, but I found myself wrong last night. This is totally different from the two sets of mechanisms. The exception handling mechanism of windows or c is called seh and structured exception handling. It is a function provided by windows itself and is not implemented by c language itself; the c ++ Exception Handling Mechanism is completely implemented by the c ++ language itself. Structured exception handling in c is mainly divided into two parts: Result cleaning, implemented through _ try and _ finally blocks, __try contains code that may generate exceptions, in _ finally, the code in _ try will generate exceptions or code executed when the Code returns normally. Therefore, some cleaning work can be done here; the other part is exception handling, implement through _ try and _ try t blocks, and the code in __try is the same as above, while the code in _ try t is the code executed after an exception is caught. As for how to handle the code in _ try and _ try t, it is determined by the exception filter. The exception filter can have three values to determine when an exception occurs, whether to execute the code in _ Wait T, or execute the statements that generate exceptions in _ try, or search the outer blocks of _ try and _ Wait T, let the outer block handle this exception. A windows structured exception can only be of the unsigned int type. The program can return different filter types based on the exception type, and then perform corresponding operations by judging the filter type. For exceptions that are not captured, the system will call the default handler for processing. This is usually the exception dialog box we often see. Generally, the last two buttons are used, you can choose to debug or terminate the program running. A serious problem is the blue screen! You can also define your own exception handler to handle exceptions that are not captured. Although the keywords such as _ try ,__ partition t ,__ finally are similar to those in C #, the mechanism is quite different. _ Try is followed by a _ finally t block or a _ finally block. The two blocks can be nested but cannot appear at the same time. There are also some local expansion, all expansion, and so on. At first, I did crash. C ++ has a better understanding of exception handling. Mainly include try, catch (...), catch (type), throw, throw (), throw (...), throw (type) and other keywords and usage, I cannot explain why c ++ does not provide keywords similar to finally? Note that any type of exception can be thrown in c ++, either an int or a class. It is interesting to note that throw (), throw (...), and throw (type) are used in the declaration of a function to indicate the types of exceptions that a function may generate. I have similar usage in Java and now I know that this mechanism is also available in c ++. In addition to the ability to generate strongly typed exceptions, the advantage of another c ++ exception is that throw can automatically analyze the objects constructed before the Exception Code in the try block. Similarly, when no catch is caught for an exception, a default processing function is used to process the exception. You can also define your own processing function. The exception handling mechanism of MFC is implemented based on c ++ (the later version of mfc) and mainly provides some macros. The main difference between Exception Handling and c ++ is that after CATCH (CException e) is processed, it will clear e, while catch () in c ++ will not; another difference is that the macro of mfc can only process CException and its derived exception classes. When writing an mfc program, you can use these different processing mechanisms together. However, c ++'s standard Exception Handling Mechanism is recommended. Since spam in c and c ++ is fully open to users, it is critical to ensure that all memory is properly recycled and processed when an application exception occurs, this requires a deep understanding of various exception handling mechanisms, using an exception handling mechanism in a program can simplify the complexity of Garbage Processing caused by different exception handling mechanisms (of course, it also reduces the complexity of other aspects ).
