Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
EXCEPTEX Traps MFC and Win32 Structured Exceptions
Article ID: 167802 - View products that this article applies to.
This article was previously published under Q167802
EXCEPTEX is a sample that demonstrates techniques for trapping of both Win32 Structured Exceptions and C++ Exceptions. For C++ exceptions, various helper functions are provided that demonstrate how to crack open the more commonly used exception classes. For Win32 Structured Exceptions, a helper function is provided that identifies the type of Win32 exception thrown.
The following files are available for download from the Microsoft Download Center:
For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.
(http://support.microsoft.com/kb/119591/EN-US/ )How to Obtain Microsoft Support Files from Online Services
Merging Win32 and C++ Exception HandlingC++ Exception handling and Win32 Structured Exception Handling use different syntax to trap exceptions.
The fundamental difference being that C++ exception handling expects to catch an instance of a type, whereas Win32 Structured Exception Handling catches only three unsigned ints.
You can, however, merge both C++ and Win32 Exception handling via the _set_se_translator() function. This causes a Win32 exception to be passed to the handler function of your choice, which can wrap Win32 Exception information in a class, and "throw" it as a C++ exception. This happens automatically when a Win32 Exception occurs, and appears seamlessly to the program as a C++ exception (see Exception Handling Differences in the VC 5.0 infoviewer). This is done for you automatically if you use the LOG macros and related support Log() functions.
In this case, LogEnable would be called once, early in the program's execution, and any Win32 exceptions raised could be caught with C++ syntax. The EXCEPTEX sample demonstrates this using the code given above.
Types of C++ ExceptionsThere are several categories of C++ exceptions that can be caught by an MFC- based program:
Below is an example of the declaration for the overloaded LogException function that catches a pointer to the MFC CException class.
LogException also tracks the file name and line number where the exception macro was last used in the call stack (if used with a helper LOG macro).
Each of these helper functions cracks open the exception and stores the results in a string array that you can process as necessary. The function for dumping the contents of this string array to the TRACE() macro is LogDisplay().
Simplifying try/catch Blocks with Helper MacrosLittering try/catch blocks in your code can get messy after a while. However, it is possible to simplify exception blocks through the use of macros. EXCEPTEX provides three macros to simplify this process, and each offers different functionality for logging/handling of exceptions. Each of the macros are also written to work for both Visual C++ 4.X and Visual C++ 5.0, so they must check the version of the compiler you are using.
Below is the simplest of the macros, LOGQ (quiet Exception Handling with no logging). It expects that a Boolean variable named bRetVal is available in your code. It must be true so that the macro can allow execution of the code that may raise an exception, and it sets it to FALSE if an exception is raised.
The #ifdef _MSC_VER restricts the definition of the macro to be specific to either Visual C++ 4.X or 5.0. The 5.0 version includes a catch for the newly introduced _com_error exception (generated by code created from #import).
You would use LOGQ as shown below:
There are two other versions of the LOG macros provided by EXCEPTEX. The second LOG macro uses the overloaded LogException() helpers described above.
This macro does not make use of the flag bRetVal. It will always execute the code encapsulated by the macro, catch any exceptions raised and log their contents.
The final LOG macro provided by EXCEPTEX, LOGR, combines both LOGQ and LOGE. It checks to see if it should execute the code and log any exception that is raised.
Other Useful FunctionsThe EXCEPTEX sample provides three more functions to assist exception handling:
LogDisplay() Dumps contents of all logged exceptions out via TRACE macros.
LogDisplay( ... ) Dumps contents of all logged exceptions out to an instance of CListBox.
LogSaveToFile( ... ) Dumps contents of all logged exceptions out to a file.
LOG.H and LOG.CPPLOG.H and LOG.CPP contain all of the code in EXCEPTEX to handle exceptions. The remainder of the sample is to demonstrate the macros/functions found in LOG.H and LOG.CPP. These two files can be easily added to an existing project, and have been written to compile in either Visual C++ 4.X or 5.0 under both ANSI and UNICODE builds. To use them, add #include "log.h" to the files that will be using the LOGE or LOGR macro. If you want to crack Win32 Structured Exceptions also, you must call LogEnable once near the beginning of your program.
Add the LOG macro in code you want to get exception data from.
Note that the file and line number reported will be the last LOG macro on the stack. If myFunction() calls myFun1() and myFun2(), you will have to wrap each function call with a LOG macro for the output to display which call the exception occurred in.
You may not always want to use the LOG macros or even the LogException() helpers as provided. They are offered both as a convenience and as well as to demonstrate comprehensive exception handling, and for logging the results of any exception caught. They are not provided as the end-all, be- all for exception handling in every production environment.
TroubleshootingThe following code shows how not to use the helper macros
This code generates a compiler error as i is only defined in the scope of the first LOGQ macro. Remember that LOGQ expands to:
/W4 and #importIf you are using the /W4 flag in Visual C++ and #import, you will see 8 warnings generated off the include files that #import utilizes.
comutil.h(905) : warning C4310: cast truncates constant valueThese error messages can be ignored and should not affect your code.
comutil.h(928) : warning C4310: cast truncates constant value
comutil.h(1030) : warning C4310: cast truncates constant value
comutil.h(1281) : warning C4310: cast truncates constant value
comutil.h(1307) : warning C4310: cast truncates constant value
comutil.h(1476) : warning C4310: cast truncates constant value
comdef.h(242) : warning C4244: 'return' : conversion from 'int' to 'unsigned short', possible loss of data
For More InformationThe following VC++ 5.0 infoviewer topic present a good introduction to exception handling techniques:
Exception Handling: Frequently Asked QuestionsThe following article demonstrates techniques that could be used to expand the EXCEPTEX sample to handle DAO SDK exceptions.
Exception Handling Differences
152695A definitive source on Win32 Exception Handling can be found in:
(http://support.microsoft.com/kb/152695/EN-US/ )How to Catch and Decipher DAO SDK-Based Exceptions
"Advanced Windows" by Jeffrey Richter, ISBN 1-57231-548-2
Article ID: 167802 - Last Review: August 5, 2004 - Revision: 3.2