Shared Source CLI Essentials

Handling Component Exceptions

Microsoft’s earlier component model, COM, used a fragile and failure-prone mechanism for dealing with violations of component contracts. Most component methods in COM returned an integer status code called an HRESULT. (Why HRESULT? Originally, it was designed to be a handle to a result and only late in the game was its definition simplified.) When COM components are deeply nested, they are supposed to check the HRESULT being returned by their subordinate components and pass errors up the stack either directly or by mapping them into new HRESULTs. As might well be imagined, this discipline is tedious, error-prone, and leads to numerous problems, including inconsistent or erroneous HRESULT checking and bloated code. It also results in lost error information, which makes debugging harder.

From the perspective of the designers of the CLI component model, structured exception handling (SEH) seemed to be at least a partial answer to many of these problems. SEH is familiar to programmers from languages such as Java and C++; what is less known is that it is also a standard part of Windows systems programming. It provides two very important capabilities for components: the ability to always execute local cleanup code declared within a finally block, and the ability to alert components further up the food chain about violations of behavioral contracts (whether malicious or innocent), providing those components with the opportunity to recover without necessitating ...