| Category: Programming |
from MSDN
Handling exceptional conditions makes your code more robust. Certain operations, including object creation and file input/output, are subject to failures that go beyond errors — out-of-memory conditions, for instance, can occur even when your program is running correctly. Anticipating and handling exceptions is a hallmark of solid code.
This article family explains the three exception handling mechanisms supplied by Visual C++.
Note : In these articles, the terms ¡°structured exception handling¡± and ¡°structured exception¡± (or ¡°C exception¡±) refer exclusively to the Win32 structured exception handling mechanism provided by Windows 95 and Windows NT. All other references to exception handling (or ¡°C++ exception¡±) refer to the C++ exception handling mechanism.
Note : MFC now uses C++ exception handling. The older MFC exception macros, if you still use them, evaluate to C++ exception keywords. See Exceptions: Changes to Exception Macros in Version 3.0.
Unlike the Win32 structured exception handling mechanism, the language itself provides support for C++ exception handling. These articles describe the Microsoft implementation of C++ exception handling, which is based on the ISO WG21/ANSI X3J16 working papers towards the evolving standard for C++.
For C++ programs, you should use C++ exception handling rather than structured exception handling. While structured exception handling works in C++ programs, you can ensure that your code is more portable by using C++ exception handling. The C++ exception handling mechanism is more flexible, in that it can handle exceptions of any type. C exceptions are always of type unsigned int.
To enable C++ exception handling in your code, open the Project Settings dialog box, select the C/C++ tab, select C++ Language in the Category box, and select Enable Exception Handling; or use the /GX compiler option. The default is /GX-, which disables exception handling unwind semantics.
Note As of version 4.0, the Microsoft Foundation Class Library (MFC), which is included with Visual C++, uses the C++ exception handling mechanism. Although you are encouraged to use C++ exception handling in new code, MFC version 4.0 and later retains the macros from previous versions of MFC so that old code will not be broken. The macros and the new mechanism can be combined as well. For information on mixing macros and C++ exception handling and on converting old code to use the new mechanism, see the articles Exceptions: Macros and C++ Exceptions, and Exceptions: Converting from MFC Exception Macros.
try-block : try compound-statement handler-list handler-list : handler handler-listopt handler : catch ( exception-declaration ) compound-statement exception-declaration : type-specifier-list declarator type-specifier-list abstract-declarator type-specifier-list ... throw-expression : throw assignment-expressionopt
The compound-statement after the try clause is the guarded section of code. The throw-expression throws an exception. The compound-statement after the catch clause is the exception handler, and catches the exception thrown by the throw-expression. The exception-declaration statement after the catch clause indicates the type of exception the clause handles. The type can be any valid data type, including a C++ class.
If the exception-declaration statement is an ellipsis (...), the catch clause handles any type of exception, including C exceptions as well as system-generated and application-generated exceptions. This includes exceptions such as memory protection, divide-by-zero, and floating-point violations. An ellipsis catch handler must be the last handler for its try block.
The operand of throw is syntactically similar to the operand of a return statement.
Microsoft Specific —>
Microsoft C++ does not support the function exception specification mechanism, as described in section 15.4 of the ANSI C++ draft.
END Microsoft Specific
With the new synchronous exception model, now the default, exceptions can be thrown only with a throw statement. Therefore, the compiler can assume that exceptions happen only at a throw statement or at a function call. This model allows the compiler to eliminate the mechanics of tracking the lifetime of certain unwindable objects, and to significantly reduce the code size, if the objects¡¯ lifetimes do not overlap a function call or a throw statement. The two exception handling models, synchronous and asynchronous, are fully compatible and can be mixed in the same application.
Catching hardware exceptions is still possible with the synchronous model. However, some of the unwindable objects in the function where the exception occurs may not get unwound, if the compiler judges their lifetime tracking mechanics to be unnecessary for the synchronous model.
See the /GX and /EH compiler options for information on enabling exception handling.