How Does Exception Handling Behavior Evolve? An Exploratory Study in Java and C# Applications

Exception handling mechanisms (EHM) were conceived as a means to improve maintainability and reliability of programs that have to deal with exceptional situations. Amongst the different implementations of built-in EHM, we classify them in two main categories: reliability-driven and maintenance-driven. Some programming languages, such as Java, provide built-in exception handling mechanisms that promote reliability-driven EHMs. Maintenance-driven EHMs, on the other hand, promote software maintainability by not forcing developers to specify exception handling constraints. Most of modern languages, such as C#, Ruby, Python and many others support this approach. Developers usually have to choose between maintainability-driven and reliability-driven approaches to structure exception handling in their applications. However, there is still little empirical knowledge about the impact that adopting these mechanisms have on software robustness and maintenance. This paper addressed this gap by conducting an empirical study aimed at understanding the relationship between changes in Java and C# programs and their robustness. In particular, we evaluated how changes in the normal and exceptional code were related to exception handling faults. We applied a change impact analysis and a control flow analysis in 116 versions of 16 C# programs and 112 versions of 16 Java programs.

I. Introduction

Exception handling mechanisms were conceived as a means to improve evolvability of programs that have to deal with exceptional situations [6], [20]. Almost all modern programming languages provide exception handling mechanisms for facilitating the development of robust and evolvable programs. All these mechanisms offer similar facilities to modularly evolve exception handling code in several ways [15], including: (i) the representation of new erroneous situations as new exception types, (ii) removal and addition of handlers (or exceptional code) for existing or new exception types, (iii) definition of code blocks (normal code) as protected regions for handling exception occurrences, (iv) new associations of these protected regions with exception handlers, and (v) changes to the exception handling policies in the exception handlers.