This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

/* A very C-style error trapping mechanism. */

#define E_FILENOTFOUND 1000

int SomeFunction()

{

// Assume something happens in this f(x)

// that causes the following return value.

return E_FILENOTFOUND;

}

void main()

{

int retVal = SomeFunction();

if(retVal == E_FILENOTFOUND)

printf("Cannot find file...");

}

This approach is less than ideal, given the fact that the constant E_FILENOTFOUND is little more

than a numerical value, and is far from being a helpful agent regarding how to deal with the prob-

lem. Ideally, you would like to wrap the error’s name, a descriptive message, and other helpful

information regarding this error condition into a single, well-defined package (which is exactly

what happens under structured exception handling).

In addition to a developer’s ad hoc techniques, the Windows API defines hundreds of error

codes that come by way of #defines, HRESULTs, and far too many variations on the simple Boolean

(bool, BOOL, VARIANT_BOOL, and so on). Also, many C++ COM developers (and indirectly, many VB6

COM developers) have made use of a small set of standard COM interfaces (e.g., ISupportErrorInfo,

IErrorInfo, ICreateErrorInfo) to return meaningful error information to a COM client.

The obvious problem with these previous techniques is the tremendous lack of symmetry. Each

approach is more or less tailored to a given technology, a given language, and perhaps even a given

project. In order to put an end to this madness, the .NET platform provides a standard technique to

send and trap runtime errors: structured exception handling (SEH).

C H A P T E R   7