Error Handling as an Aspect Fernando Castor Filho 1 , Alessandro Garcia 2 , Cec´ ılia Mary F. Rubira 3 1 Department of Computer Science, University of S˜ ao Paulo Rua do Mat˜ ao, 1010. 05508-090, S˜ ao Paulo, SP, Brazil 2 Computing Department, Lancaster University South Drive, InfoLab 21, LA1 4WA, Lancaster, UK 3 Institute of Computing, State University of Campinas P.O. Box6176, 13084-971, Campinas, SP, Brazil fernando@ime.usp.br, garciaa@comp.lancs.ac.uk, cmrubira@ic.unicamp.br ABSTRACT One of the fundamental motivations for employing exception handling in the development of robust applications is to lex- ically separate error handling code from the normal code so that they can be independently modified. However, ex- perience has shown that exception handling mechanisms of mainstream programming languages fail to achieve this goal. In most systems, exception handling code is interwined with the normal code, hindering maintenance and reuse. More- over, because of limitations in the exception handling mech- anisms of most mainstream programming languages, error handling code is often duplicated across several different places within a system. In this paper we present a pat- tern, Error Handling Aspect, which leverages aspect-oriented programming in order to enhance the separation between error handling code and normal code. The basic idea of the pattern is to use advice to implement exception handlers and pointcuts to associate advice to different parts of the normal code in order to improve the maintainability of the normal code and promote reuse of error handling code. Categories and Subject Descriptors D.2.3 [Software Engineering]: Coding Tools and Tech- niques General Terms Languages, Design Keywords exception handling, aspect-oriented programming 1. INTRODUCTION Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Workshop BPAOSD’07, March, 12-13, 2007 Vancouver, BC, Canada Copyright 2007 ACM 1-59593-662-2/07/03 ...$5.00. Exception handling [7] mechanisms were conceived as a means to structure programs that have to cope with erro- neous situations. These mechanisms make it possible for developers to extend the interface of an operation with ad- ditional exit points that are specific to error recovery. More- over, they define new constructs for raising exceptions and associating exception handlers with selected parts of a pro- gram. Ideally, an exception handling mechanism should en- hance attributes such as reliability, maintainability, reusabil- ity, and understandability, by making it possible to write programs where: (i) error handling code and normal code are lexically separate and can be maintained independently [17]; (ii) the impact of the code responsible for error handling in the overall system complexity is minimized [18]; and (iii) an initial version that does little recovery can be evolved to one which uses sophisticated recovery techniques without a change in the structure of the system [17]. 1.1 Problem Even though separation of concerns is the overarching goal of exception handling, the kind of separation promoted by the exception handling mechanisms of most mainstream object-oriented programming languages brings only limited advantages [3, 8, 15]. In languages such as Java, Ada, C++, and C#, it is not possible to “plug” and “unplug” excep- tion handlers. In these languages, the normal code and error handling code are entwined within fine-grained units (code blocks), making it hard to maintain the former indepen- dently from the latter. Also, this hardwiring of the exception handling code to the normal code hinders reuse of normal code across different applications, as these applications often have different requirements pertaining error handling. Another problem is that the exception handling mech- anisms of the aforementioned languages only support the definition of handlers that are local to specific parts of a program. Reuse of error handling strategies within an ap- plication is possible only to a certain degree, by extracting error handling measures to new methods. However, in most mainstream programming languages, the code that catches exceptions and initiates an exception handling measure has to be scattered throughout the application. As a conse- quence, most systems have a considerable amount of dupli- cated exception handling code. For example, consider the following Java code snippet, extracted from an Eclipse plu- gin: