Fault Handling

Rule 58.(MFC Specific) Use standard C++ exception-handling mechanism (try,catch, andthrowstatements) instead of the MFC exception macros.

Rec. 69.Do not use Win32 structured exception handling.

Rec. 70.Check the fault codes that may be received from library functions even if these functions seem foolproof.

Rec. 71.Use_ASSERT,_ASSERTE, or similar macros to check assumptions during the debugging process.

There are two mechanisms available in MFC:

• C++ exceptions available in MFC version 3.0 and later.

• The MFC exception macros, available in MFC version 1.0 and later.

If you write a new application using MFC, you should use the C++ mechanism. You can use the macro-based mechanism if your existing application already uses that mechanism extensively.

Structured exception handling (__try,__except, and__finallystatements) is a Microsoft extension and works with Win32 for both C and C++ source files. However, it is not specifically designed for C++. You can ensure that your code is more portable by using C++ exception handling. In addition, C++ exception handling is more flexible, in that it can handle exceptions of any type. For more information, seeException Handling Topics (C++)in the MS Visual C++ documentation.

Two important characteristics of a robust system are that all faults are reported and, if the fault is so serious that continued execution is not possible, the process is terminated. In this way, the propagation of faults through the system is avoided. It is better to have a process crash, than to spread erroneous information to other processes. In achieving this goal, it is important to always test fault codes from library functions. The opening or closing of files may fail, allocation of data may fail, etc. One test too many is better than one test too few. Your own functions should preferably not return fault codes, but should instead take advantage of exception handling.

However, note that the extra overhead associated with the C++ exception handling mechanism may increase the size of executable files and slow program execution time. Thus, exceptions should be used only to signal the occurrence of unusual or unanticipated program events. Exception handlers should not be used to redirect the program's normal flow of control. For example, an exception should not be thrown in cases of potential logic or user input errors, such as the overflow of an array boundary. In these cases, simply returning an error code may be simpler and more concise. Judicious use of exception handling constructs makes your program easier to maintain and your code more readable.

The _ASSERT,_ASSERTE, and similar macros (such as MFCASSERTandVERIFY)provide an application with a clean and simple mechanism for checking assumptions and printing erroneous ones during the debugging process. They are very flexible because they do not need to be enclosed in#ifdef/#endifstatements to prevent them (exceptVERIFY) from being called in a retail build of an application. This flexibility is achieved by using the_DEBUGmacro._ASSERT,_ASSERTE, andASSERTare only available when_DEBUGis defined. When_DEBUGis not defined, calls to these macros are removed during preprocessing.VERIFYis evaluated in both debug and release versions of your application, but prints an error message only in debug environment.