来源于《深入C++对象模型》

The primary implementation task in supporting exception handling (EH) is to discover the appropriate catch clause to handle the thrown exception. This requires an implementation to somehow keep track of the active area of each function on the program stack (including keeping track of the local class objects active at that point in the function). Also, the implementation must provide some method of querying the exception object as to its actual type (this leads directly to some form of runtime type identification (RTTI)). Finally, there needs to be some mechanism for the management of the object thrown梚ts creation, storage, possible destruction (if it has an associated destructor), clean up, and general access. (There also may be multiple objects active at one time.) In general, the EH mechanism requires a tightly coupled handshake between compiler-generated data structures and a runtime exception library. The implementation tradeoff is between program size versus the runtime speed of the program when no exception is being handled:

• To maintain execution speed, the compiler can build up the supporting data structures during compilation. This adds to the size of the program, but means the compiler can largely ignore these structures until an exception is thrown.
• To maintain program size, the compiler can build up the supporting data structures “on the fly” as each function is executed. This affects the speed of the program but means the compiler needs to build (and then can discard) the data structures only as they are needed.

According to [CHASE94], the Modula-3 Report has actually “institutionalized” a preference for maintaining execution speed at the expense of program size by recommending “that 10,000 instructions may be spent in the exceptional case to save one instruction in the normal case.” That tradeoff is not universal, however. At a recent conference in Tel Aviv, I was speaking with Shay Bushinsky, one of the developers of “Junior,” a chess program that tied for third place with IBM’s “Deep Blue” in the winter 1994 world computer chess championship. Surprisingly, the program runs on a Pentium-based personal computer (Deep Blue uses 256 processors). He told me that when they recompiled it under the version of the Borland compiler that incorporated EH, it no longer fit in available memory even though nothing in the program changed. As a result, they had to fall back to an earlier version of the compiler. For “Junior,” a bigger but noninvasive runtime program is not an option. (Nor, on the other hand, would the runtime impact of building up the data structures on the fly likely be acceptable. Support for EH brings with it additional overhead whether or not an exception is thrown.)

It is also worth noting (in passing) that EH literally killed off cfront. It is simply not possible to provide an acceptably robust EH mechanism without the support of the code generator (and linker). The UNIX Software Laboratory (USL) sat on the C-generating implementation of EH delivered by Hewlett-Packard for over a year (see [LENKOV92] for a discussion of their portable implementation and its performance). USL finally threw up its collective hands and canceled plans for a Release 4.0 and for any further development of cfront.

翻译得一塌糊涂！！！！