Presented by Eduardo Silva. A copier has more lines about exception handling than on functionality. That is what I remember from one of my fellow architects. Error recovery techniques are used to improve software robustness. Most languages have native support for this ( the “try-catch”-blocks for example). Architecture erosion is typically the effect of uncontrolled evolution over time. Typically, exception handling is not very well documented, so it is an additional risk to erosion.
ArCatch provides a declarative language and a design rule checker for exception handling. It provides means to model exceptions on the level of the architecture. It has six architectural concepts: raising, signaling, handling, rereaising, remapping and flows. ArCatch takes both the source code and the architecture as input to validate the rules. There is a formal semantics backing the tool and the language.
To validate the language they performed a case study on Health Watcher (HW), which is a Java-based open source system. They evaluated 10 versions (7k to 10k LOC). It has a 4-layered architecture. Data collection consists of repository mining to extract the code, and define the design rules. Next, they interviewed architecture to confirm the rules, and after analysis they did a second interview. They first mapped the source code to the different layers, and then did the same for the exceptions. They had to do this for each version. HW uses one of the Oracle’s Blueprints design principle: the layer directly above is responsible for handling exceptions.
The analysis resulted in nice observations, e.g. that new versions introduce violations that previously were not there, or vice versa. The case study shows that it is useful in the identification of existing exception handling erosion problems. However, usability of the approach is not yet studied. Also, it is interesting to see whether one can derive tests from the ArCatch specification.