A Systematic Approach for Structuring Exception Handling in Robust Component-Based Software

This article addresses the systematic incorporation of exception handling into component-based systems. By "component-based", one can infer "object-oriented" since the use of libraries of classes, such ast STL and JCL, can be seen as the use of components, building blocks, while constructing large-scale software systems. Read this article in its entirety to get a sense of how to put exception handling to good use.

5. Case Study

5.5 Discussion

The most important benefit of applying our approach to the CMS was enhanced system structure. The implementation of the system bore a greater resemblance to its design and the code responsible for the exceptional behaviour was more clearly separated. The main consequence of this fact is decreased complexity. Moreover, exceptions are confined to where they are semantically meaningful. For instance, in our case study, the system layer did not have to handle any exception directly related to the database. Hence, components are more reusable, because they only have to deal with exceptions that are directly related to their conceptual domains.

Component-based systems built according to our proposed approach are also more robust, for two main reasons:

  1. The specific exception handlers share responsibilities for exception handling at different levels of semantics abstraction. The most concrete and implementationdependent level is assigned to ALE handlers, while the most abstract and system-dependent level is assigned to CLE handlers. Thus, specific exception handling strategies can be employed at each semantic level, preserving the system's independence of its component's implementations. This improves the substitutability of the system's components and, hence, also improves its robustness.
  2. Our exception handling strategy includes concrete guidelines about how a component should react to unanticipated exceptional conditions. This kind of design decision is not left open to the component developer. This avoids the situation where, in absence of a specification, the developers adopt bad practices such as: swallowing an exception, including an empty catch block, and propagating an exception that is meaningless to the component's client.

CLE handlers guarantee that exceptions a component receives are compatible with the abstract exception type hierarchy, as discussed in Section 5.2. Hence, there is always some semantic information regarding the error that can be taken into account by handlers. Furthermore, the exceptions in the abstract exception type hierarchy provide some information regarding the state in which the component that signalled the exception was left. This is important for error diagnosis and recovery.

The intra-component strategy for reusing OTS components proved to be useful. To reuse the initial implementation of the ComplaintMgr component, no modifications were required to other elements of the system. All we had to do was to deploy the robust implementation (reused ComplaintMgr plus provided interface interceptor and BLE handlers) as if it were the initial implementation. This is an important benefit of applying the proposed approach.

The implementation overhead of applying our strategy in an existing system is not negligible. In our case study, the robust implementation of the CMS had 9.54% more lines of code than the initial implementation (9747 loc of the original version against 10677 loc of the new one, ignoring automatically generated code). Although the robust implementation is larger, it is also better structured.

Our strategy also imposed a development time overhead, due to specification and implementation activities. The time it took for the developer to perform the three activities described in Section 4.4 throughout requirements, specification, provisioning, and assembly workflows accounted for more than 30% of the time required for the development of the initial implementation.