2012 IEEE 14th International Symposium on High-Assurance Systems Engineering

Exception Handling Defects: An Empirical Study

Puntitra Sawadpong , Edward B. Allen and Byron J. Williams Department of Computer Science and Engineering Missisippi State University Mississippi State, Mississippi 397629637 Email: ps402@msstate.edu, edward.allen@computer.org and williams@cse.msstate.edu

AbstractException handling mechanisms are a feature common in many programming languages. Improper handling of exceptions can cause failures in software systems. This is especially critical for high-assurance systems where software failures may have severe consequences. Understanding the impact of misusing exception handling is important for better utilization of these constructs. This paper presents an exploratory study to determine whether using exception handling is relatively risky by analyzing the defect densities of exception handling code and the overall source code. Also, statistics representing the prevalence of exception handling code are proposed. The study was conducted with six major Eclipse releases. Essential data was collected using custom scripts to extract exception handling information from the source code and exception handling defects information from bug reports. We found that the density of defects that are closely related to exception handling constructs is relatively high compared to the overall defect density. This implies a relationship between the use of exception handling constructs and the risk of defects. Further studies should be conducted to better determine proper ways to implement exception handling and the root causes of exception defects in the software systems. Keywords-empirical study; exception handling; measurement; defects; Eclipse

I. I NTRODUCTION Exception handling is one of the advanced topics in most programming languages [1], [2]. Exception handling constructs serve to process unexpected events so the program does not crash or experience other unintended behaviors [3], [4], [5], [6]. However, when exceptions are not handled properly, there may be serious consequences. In Java, the Java Virtual Machine (JVM) provides a default exception handling mechanism. In general, when an uncaught exception occurs and no handler exists, the stack trace is produced and the thread is terminated. This behavior has the same result as a try/catch block with only a print stack trace statement inside the catch block [7]. Such behavior is usually unacceptable in high assurance systems. One of the motivations of this paper is the case of the Ariane 5 [8], [9] in June 1996, a widely-known example of accidents in software engineering. The maiden ight of the Ariane 5 launcher angled off its path, broke up and then exploded around 40 seconds after ignition, causing a $500 million nancial loss. The key to this tragic incident was misuse of the exception handling mechanism. The inertial
1530-2059/12 $26.00 2012 IEEE DOI 10.1109/HASE.2012.24 90

reference system, which is a part of the ight control system, did not send correct attitude data to the on-board computer software because the unit failed as a result of an exception in the inertial reference system. The exception occurred when a 64-bit oating point value was converted to 16-bit signed integer value. The value of the oating point number exceeded the maximum for a 16-bit signed integer value. This led to an operand error that was caught by the exception handling mechanism. However, instead of trying to give estimated attitude information to the onboard computer or perform other recovery actions, both inertial reference system software units were terminated. This incident could have been avoided by more cautious design and implementation of exception handling [10], [11], [12]. In 1980, Hoare talked about exception handling in his Turing award lecture, ...Gradually, these [Ada design] objectives have been been sacriced in favor of power, supposedly achieved by a plethora of features and notational conventions, many of them unnecessary and some of them, like exception handling, even dangerous... [13]. Back then, software systems were neither as complex nor as safety critical as software systems of today. Also, exception handling was not an enforced feature of any programming language, which is not the case today (e.g., Java). Therefore, we cannot conclude that exception handling mechanisms are unneccessary any more, because there are many more errors to handle especially in high-assurance systems or complex safety critical systems [1]. The main goal of this study was to answer the question Is exception handling risky?. Our literature review found that few studies have addressed this issue [14]. We conducted a preliminary study of exception handling use and defects from major releases of Eclipse. The defects related to exception handling will be called exception defects in this study. From the Oxford Dictionary, one of the meanings of risk is the possibility that something unpleasant or unwelcome will happen. In software engineering, the occurrence of a defect can easily be considered an unpleasant or unwelcome event. The risk of exception handling defects is summarized by the defect density of exception handling constructs. Moreover, the prevalence of exception handling can be measured to determine the frequency of the exception handling

constructs in the source code. Statistics representing the prevalence of exception handling are presented in this paper. Exception handling is risky if the defect density is high for exception handling constructs. Also, exception handling is a concern when the prevalence is large. The rest of this paper is organized as follows. Section II highlights related work. Section III explains the study methodology, study subjects, tools used for collecting data, and the quantitative results obtained. Section IV presents the quantitative analysis. Qualitative and quantitative analysis of the results are discussed in Section V. Threats to validity are addressed in Section VI. Finally, section VII summarizes the results, gives conclusions of the study, and outlines possible future work. II. RELATED WORK To the best of our knowledge, there is only one study that empirically addresses the relationship between exception handling and defects. Marisnescu [14] conducted an empirical study to investigate whether classes that use exception handling are more defect prone than classes that do not use exception handling. Her study analyzed three versions of Eclipse, namely, 2.0, 2.1 and 3.0. The number of classes that used exception handling and the number of classes that did not use exception handling for each release were collected. Prerelease and post-release defect information of each release was extracted from CVS and Bugzilla to see whether defects were in an exception class or non-exception class. Then, a chi-squared test was performed to calculate the odds ratios between two categories of classes (exception classes and non-exception classes) for both pre-release and post-release defects. The results show that classes that used exceptions were more likely to exhibit defects than classes that did not have exception handling constructs for both pre-release and post-release defects. To better account for size, we investigated risk from a different perspective by analyzing the exception defect density and the overall defect density of the post-release defects. We also propose a measure of prevalence of exception handling. Therefore, a new study methodology was designed and performed instead of repeating Marisnescus procedure [14]. Exception handling mechanisms seem to be neglected in the software engineering literature, but some researchers have pointed out their importance. Shah et al. [15] studied the viewpoints of novices and experts in the software industry. The study indicates that novice developers are likely to ignore exceptions when developing a system because exception handling is complex. Some of them use exception handling mainly for debugging the code. However, expert developers think that exception handling is an important part in the development process. Both usual and exceptional behavior should be considered concurrently during

developing the system. Brock [16] points out that bad exception handling implementations can affect the quality of the software. She presents some techniques, guidelines and design patterns for implementing exception handling. The preceding studies warrant further examination of exception handling constructs as their benets and risks have not been thoroughly vetted. III. STUDY METHODOLOGY This study tries to answer whether using exception handling is risky by analyzing the defect density related to exception handling constructs compared to the overall defect density. If the defect density of exception handling constructs is high especially when compared to the overall defect density then implementing exception handling may be risky. On the other hand, if the defect density of exception handling constructs is low, then implementing exception handling mechanism is less risky. Two Python scripts were implemented to aid in this process. The rst one analyzes a Java project and gives general metrics of that release such as source lines of code (SLOC), number of Java les, etc. and exception handling information. The second script was developed to fetch the defect information from Bugzilla, perform keyword searches and provide the number of defects related to exception handling. A. Collecting Exception Handling Data Exception handling constructs in this study include all try/catch and throw statements which could be in the following forms [17]. A try statement followed by a single catch statement and/or nally statements A try statement followed by multiple catch statements and/or nally statements Nested try/catch/nally statements All throw statements located outside try/catch statements All throw statements located in any try/catch statement are considered part of that try/catch statement Exception classes are those with one or more exception handling constructs. However, other forms of exception declarations and extending exception classes are not considered in this study because we want to focus on exception handling constructs only as dened above. The input of the script is a parent directory path of the project that we want to analyze. With a given directory path, the script traverses through all directories and subdirectories to locate all Java les. After that, each le is analyzed to obtain required information including the following information: General information such as source lines of code (SLOC) and number of Java les. Source lines of code means only non-comment and non-whitespace lines of

91

Table I S EVERITY VALUES AND M EANINGS Value Blocker Critical Major Normal Minor Trivial Enhancement Intended meaning Prevents function from being used, no workaround, blocking progress on multiple fronts Prevents function from being used, no workaround Prevents function from being used, but a work-around is possible A problem making a function difcult to use but no special work-around is required A problem not affecting the actual function, but the behavior is not natural A problem not affecting the actual function, a typo would be an example Request for enhancement

No. post-release exception defects 2500 2000 1500 1000 500 0

No. post-release non-exception defects

Figure 1. Comparison between total post-release non-exception defects and post-release exception defects

this study we considered only major releases; minor releases were not included. code. White spaces and lines containing comments only are not included. Exception handling information such as number of exception handling constructs, number of les with exception handling constructs and number of exception lines of code. All of this information is shown in Table II. B. Study Subjects Six Eclipse releases were chosen as the study subjects. The Eclipse project was rst developed by IBM in 2001. Currently, the Eclipse releases are hosted by the Eclipse Foundation, which was created in 2004. The Eclipse Foundation is an independent not-for-prot corporation that administers the Eclipse community, which is an open source community. There are both full-time staff and volunteers in the Eclipse community working on Eclipse projects [18]. Eclipse is a software development environment consisting of an extensible plug-in system and integrated development environment (IDE). Eclipse is primarily written in Java. We chose to evaluate Eclipse because it is a mature and relatively large product and we have full access to its source code and bug reports. Moreover, the Eclipse community follows standard programming practices and has well dened defect reports [19]. Also, Eclipse source code has high prevalence of exception handling constructs. Although a development environment is not a critical system on the surface, high reliability is required so that it can be used to develop high assurance products. We selected Eclipse releases 3.1 through 3.6 as study subjects because we wanted to be certain that both prerelease and post-release defects that we analyze were all resolved. Therefore, we ruled out Eclipse release 3.7 because the post-release period of release 3.7 ended late in December 2011, and thus some reported defects might have not yet been resolved by the time of our study in early 2012. Also, in C. Collecting Defects information In this study, pre-release defects are defects reported during the 6 months period before the ofcial release date. Post-release defects are defects reported during the 6 months period after the ofcial release date [20]. Each bug reported in Bugzilla has a severity eld which indicates the severity of the impact of that defect. The builtin values and meaning of each severity are shown in Table I [21]. We dene exception defect as any defects that are related to exception handling constructs. For example, any event that raises an exception, terminates after an exception is caught, or any event that is thrown is an exception defect. In order to obtain exception defect numbers reported in Bugzilla, another Python script was implemented. First, lists of all defect identiers of each version were obtained manually and stored in text les. At this stage, all defects identied as duplicate and invalid were removed. Invalid defects, marked as INVA, usually happened when the user reported an intended behavior as a bug or the bug does not belong to Eclipse. The script processes the list of defect identifers then fetches each bug reporting page and performs keyword searches by searching for terms exception, throw or threw to determine whether or not that defect is related to exception handling. In this study, enhancement defects are not considered because we want to analyze only actual defects of the system not requests for enhancements. Apart from categorizing defects by release numbers, we also categorize defects of each release into 2 phases, namely, pre-release and post-release defects. The defect prole of overall pre-release, post-release and exception defects are displayed in Table III. Figure 1 shows the trend of postrelease non-exception defects and post-release exception defects over time. Table IV displays the numbers of exception defects by

92

Table II G ENERAL M EASUREMENTS OF E CLIPSE R ELEASES Release Metric Total java les No. les with exception No. les without exception Total exception constructs Total SLOC SLOC of les with exception SLOC of les without exception Total exception SLOC 3.1 (N/A) 12300 4058 8242 16825 1595837 968714 627123 143160 3.2 (Callisto) 14620 4767 9853 19380 1893437 1158570 734867 167756 3.3 (Europa) 16036 5103 10933 20955 2087566 1262222 825344 180933 3.4 (Ganymede) 18092 5644 12448 23216 2346114 1398714 947400 198424 3.5 (Galileo) 18836 6047 12789 25547 2463001 1517064 945937 217769 3.6 (Helios) 20599 6638 13961 27978 2674520 1653658 1020862 236391

Table III N UMBER OF PRE - RELEASE AND POST- RELEASE DEFECTS OF EACH RELEASE Release Defect Types Pre-release Post-release All Pre-release exception Post-release exception All exception 3.1 (N/A) 7437 1998 9435 1654 385 2039 3.2 (Callisto) 5690 1884 7574 1104 360 1464 3.3 (Europa) 4635 1685 6320 883 351 1234 3.4 (Ganymede) 3689 1314 5003 691 303 994 3.5 (Galileo) 3051 909 3960 587 203 790 3.6 (Helios) 2123 628 2751 479 152 631

Table IV T HE N UMBER OF E XCEPTION D EFECTS BY S EVERITY L EVEL Release Severity Blocker Critical Major Normal Minor Trivial 3.1 8 13 46 298 14 6 3.2 4 23 42 284 6 1 3.3 9 8 57 259 14 4 3.4 3 16 35 238 7 4 3.5 0 5 25 164 9 0 3.6 2 8 19 118 4 1

Table V T HE N UMBER OF N ON -E XCEPTION D EFECTS BY S EVERITY L EVEL Release Severity Blocker Critical Major Normal Minor Trivial 3.1 13 22 151 1274 109 44 3.2 11 35 136 1194 106 42 3.3 8 14 103 1071 92 46 3.4 5 16 73 812 77 28 3.5 1 8 61 541 63 32 3.6 1 27 54 330 38 36

severity level of each release. Table V shows the numbers of non-exception defects by severity level. IV. ANALYSIS Risk and prevalence are the main concepts addressed by this study. This section presents the rationale behind our quantitative results. We measure risk by calculating defect density. Defect density is a measure of the number of known defects detected per unit of software or component size. The size unit in this study is a thousand lines of non-comment source code. Moreover, we focus only on post-release defects due to space constraints. Pre-release defects are usually found by the test team or internal customers during the development

process. While post-release defects are mostly discovered by the users or external customers during operation. Therefore, post-release defects have more severe consequences for users and are far more expensive to x than pre-release defects. High defect density means high risk while low risk is indicated by low defect density. Overall Defect Density is used as a baseline for analyzing risk. The Overall Defect Density is the ratio of the total number of post-release defects to the size of the software (see Equation (1)). Overall Defect Density = Total Number of Defects Total SLOC 103

(1)

93

Next, a class with at least one exception handling construct is called an exception class. A defect containing the keyword exception is called an exception defect. The exception defect density of exception classes is measured by the number of exception defects divided by source lines of code of exception classes as shown in Equation (2). This tells us the density of exception defects that reside in exception classes only. Other defects in exception classes that are not related to exception handling are excluded. Exception Defect Density of Exception Classes = Number of Exception Defects (2) SLOC of Exception Classes 103 The exception defect density of exception constructs is measured by the number of exception defects divided by source lines of code of exception constructs as shown in Equation (3). This tells us the density of exception defects that are closely related to exception handling constructs. Exception Defect Density of Exception Constructs = Number of Exception Defects (3) Exception Lines of Code 103 Moreover, we can measure the risk of code that is not related to exception handling by calculating the non-exception defect density which is shown in Equation (4). This defect density is the ratio of the number of non-exception defects (defects that are not related to exception handling) to the portion of code that does not contain exception handling constructs. Non-Exception Defect Density = Number of Non-Exception Defects (4) (Total SLOC Exception Lines of Code) 103 Equation (5) calculates the number of exception defects out of the total number of overall defects by directly comparing both quantities.
Exception Defect Ratio = Number of Exception Defects (5) Total Number of Defects

Table VI D EFECT D ENSITIES Release Defects/KSLOC Overall Density Defect 3.1 1.252 0.397 3.2 0.995 0.311 3.3 0.807 0.278 3.4 0.560 0.217 3.5 0.369 0.134 3.6 0.235 0.092

Exception Defect Density of Exception Classes Non-Exception Defect Density Exception Defect Density of Exception Handling Constructs Exception Ratio Defect

1.110 2.689

0.883 2.146

0.700 1.940

0.471 1.527

0.314 0.932

0.195 0.643

0.193

0.191

0.208

0.231

0.223

0.242

small portion of the source code. If exception classes are widespread in the source code, the prevalence value is high. Prevalence of SLOC of Exception Classes = SLOC of Exception Classes (6) Total SLOC We also determine whether classes containing exception handling constructs are prevalent compared to the total number of classes (shown in Equation (7)). Prevalence of Exception Classes = Number of Exception Classes (7) Total Classes Prevalence of Exception Constructs in the exception classes as shown in Equation (8), tells us if the exception handling constructs are a large portion of the lines of code in exception classes. Prevalence of Exception Constructs = Exception Lines of Code (8) SLOC of Exception Classes The prevalence values of exception handling of Eclipse 3.1 through 3.6 are displayed in Table VII. We discuss the application of the above formulas related to our research questions in the next section. V. DISCUSSION Is exception handling risky or not in terms of defect densities? How prevalent are the exception handling constructs in the source code? The prevalence gives perspective on the degree of risk. Exception handling is risky when the value of exception defect density is high. If the prevalence of exception handling is also high, the degree of risk is elevated.

The quantitative results of the risk or defect densities and the exception defect ratio are shown in Table VI The concept of prevalence is dened as how common exception handling constructs are in the source code. The prevalence of exception handling implementations can be determined by comparing the size of exception handling code to the total size. Equation (6) calculates the prevalence as SLOC of exception classes divided by total SLOC of all classes. Low prevalence of SLOC of exception classes means classes with exception handling constructs are a

94

Table VII P REVALENCE OF EXCEPTION HANDLING Release 3.1 Prevalence of SLOC of Exception Classes Prevalence of Exception Classes Prevalence of Exception Constructs 3.2 3.3 3.4 3.5 3.6 0.607 0.612 0.605 0.596 0.616 0.618 0.330 0.326 0.318 0.312 0.321 0.322

350 300 250 200 150 100 50 3.1 3.2 3.3 3.4 3.5 3.6

0.148 0.145 0.143 0.142 0.144 0.143

In general, the number of both pre-release and post-release defects of Eclipse 3.1 through 3.6 gradually decreased over time. In other words, the reliability of the system has been improved over time. This might be a result of better testing methodology or development processes. The fact that the number of defects decreases over time was reected in the defect densities. Figure 5 shows the defect densities of Eclipse over 6 years. Considering the trends of defect densities, all of them slowly declined. Therefore, the defect densities of the lastest release of the study subjects (3.6) is discussed in this section to represent all the older releases which have a similar prole. Table VII also shows that every release has almost identical prevalence gures. Thus, only the results of the latest release are discussed. The overall defect density is used as a baseline in analyzing the risk of exception handling. In Eclipse 3.6, the overall defect density is 0.235 defects per KSLOC. Compared to the overall defect density, the value of the defect density of exception classes is substantially lower. The defect density of exception classes only represents the density of the exception defects regardless of the other defects in the exception classes. Since the size of exception classes (shown in Figure 4) is considerably higher than the size of non-exception classes, the defect density of exception classes is very low. Likewise, the non-exception defect density (0.195 defects per KSLOC) is slightly lower than the baseline defect density. However, the defect density of exception handling constructs (0.643 defects per KSLOC) is much higher than the overall defect density and other defect densities. This indicates that the defect density of defects that are closely relately to exception handling constructs is high and more risky than the baseline. Like defect densities, every release also has a similar prole of exception defects at each severity level (see Table IV). The majority of exception defects are normal defects while the second-most are major defects (see Table I). This implies that the exception defect density of exception handling constructs is not only high, but the severity levels are also a concern. Figure 2 and Figure 3 show that both exception defects and non-exception defects have similar distributions. Based on the results, the prevalence of SLOC of exception

Figure 2.
1400 1200 1000 800 600 400 200 0

Distribution of Exception Defects Based on Severity

3.1 3.2 3.3 3.4 3.5 3.6

Figure 3.

Distribution of Non-Exception Defects Based on Severity

classes of release 3.6 has the highest value (0.618). This is a result of large exception class size compared to nonexception class size. The prevalence of exception classes is 0.322, which means that the classes that have exception handling constructs are common. On the other hand, the prevalence of exception handling lines of code is smaller but still substantial (0.143), considering the fact that exception handling is not the main purpose of the software. Compared to the overall source code, exception handling constructs are

SLOC of classes without exception handling constructs SLOC of classes with exception handling constructs 3000000 2500000 2000000 1500000 1000000 500000 0

Figure 4. Comparison between the size of classes with exception handling constructs and classes without exception handling constructs

95

 K E

be addressed by extending the analysis to other systems and programming languages. VII. C ONCLUSION Our goal was to determine whether using exception handling is risky by performing measurement of source code and analyzing bug reports. Eclipse releases which have a high prevalence of exception handling constructs were selected as the study subjects. We compared the exception defect densities to the overall defect density and compared the exception defect ratios. We also proposed statistics to calculate the prevalence of exception handling code. To analyze the source code, we implemented a script capable of extracting the number of exception handling constructs and the number of source lines of code of exception handling code. The script also collects other general information from the code such as the number of Java classes and source lines of code. Bug reports were investigated to determine which defects are related to exception handling. In order to do so, a second tool was implemented to perform keyword searching on Bugzilla to determine whether that defect is related to exception handling. The results show that the exception defect density of exception handling constructs are approximately three times higher than the overall defect density. For example, in release 3.6 the overall defect density is 0.235 defects per KSLOC and the exception defect density of exception handling constructs is 0.643 defects per KSLOC (see Table VI). The exception defect ratios are over 20%. Even though the overall number of defects decreases over time, the trend of the exception defect ratios slightly increases. Exception handling mechanisms are advanced features of most modern programming languages that many programmers neglect [15]. However, it is important to understand this feature because todays software systems, especially high assurance or safety critical systems, have more complex functionalities. Also, in some programming languages such as Java, exception handling is enforced [22]. Furthermore, there might be severe consequences when errors are not handled properly, especially in safety critical systems [12]. This study explored whether using exception handling has a high possibility of defect occurance. We found that in Eclipse releases, the exception defect density of exception handling constructs is much higher than the overall defect density. We believe implementing exception handling mechanisms is essential for software systems especially safety critical and high assurance systems. Careful planning, design, implementation and testing are crucial. The results tell us that using exception handling is risky and further studies should be conducted to nd the root causes of exception defects and thoroughly understand the correlation between exception handling and defects in the software systems.

Figure 5.

Defect Densities of Eclipse 3.1 3.6

a small portion of the source code. Although the overall number of defects is declining over time, the trend of exception defect ratio in Table VI is slightly increased. The fact that the defect density of exception handling constructs is relatively high tells us that developers should pay more attention to implementing and testing exception handling code compared to normal code. VI. THREATS TO VALIDITY In this study there are several threats to validity, both internal and external. Internal threats to validity are concerned about the appropriate use of methods and tools including the consistency of the measurements. The internal threats to validity are from the data collection process, both source code and bug reports. The use of a keyword searching strategy to extract the defect information is a threat to validity, because exception defects that are not caused by exception handling constructs, such as defects found in the code that requires exception handling, might be included by the script. Even though the false positive rates of both programs have not been quantitatively tested, they were manually tested by sampling to make sure the results are acceptably accurate. External threats to validity are concerned with the degree of generalization of the study. There are two external threats to validity, namely, the generalization of the study and the applicability of the tool to other programming languages. The six major Eclipse releases studied are not generalized to the population of every classication of software. Exception handling mechanisms might not be implemented in all software systems or exception handling in other programming languages might have other issues. Eclipse is an opensource, user support type of application used mainly by developers. It is as well written in Java. Also, the sizes of our subjects are considered medium to large. All of these issues affect the generalization of our study. Our second external threat to validity is the applicability of the tool. The tools implemented for this study were designed for analyzing Java code and fetching data from Bugzilla only. This threat can

96

Finally, we hope this study benets the software engineering research community by stressing the importance of the exception handling mechanism. This study is a start for research in this area. We plan to repeat the same study methodology with other data sets to improve the generalization of the study. With an improved tool, similar studies can be performed with systems written in other programming languages to see whether our results are widely applicable. Commercial software systems would also be a good source of projects to empirically analyze. The false positive rates of both scripts can be quantitatively evaluated to mitigate internal threats to validity. Further study can also be done to investigate why exception handling constructs cause defects? What are the root causes of exception defects? Is there any correlation between exception handling and defect location. Also, which software systems implement exception handling mechanisms and what types of exceptions are handled? An empirical study on whether exception handling code is more complex than non-exception handling code would help explain why using exception handling is risky. ACKNOWLEDGMENT We would like to thank the Empirical Software Engineering Research Group at Mississippi State University for weekly presentations that inspire and open our vision for software engineering research. Finally, we would also like to thank Dae Glendowne and James Thomson for reviewing and providing valuable comments. The ndings and opinions in this paper belong solely to the authors. R EFERENCES
[1] S. J. Drew and K. J. Gough, Exception handling: Expecting the unexpected, Computer Languages, vol. 20, no. 2, pp. 6987, 1994. [2] C. de Dinechin, C++ exception handling, IEEE Concurrency, vol. 8, no. 4, pp. 7279, 2000. [3] J. Xu, A. Romanovsky, and B. Randell, Concurrent exception handling and resolution in distributed object systems, IEEE Transactions on Parallel and Distributed Systems, vol. 11, no. 10, pp. 1019 1032, Oct 2000. [4] S. Jiang and B. Xu, An efcient and reliable object-oriented exception handling mechanism, ACM SIGPLAN Notices, vol. 40, no. 2, pp. 2732, 2005. [5] R. Wong and E. Yung, Exception handling in C++ without language extension, in Proceedings of the 1993 IEEE Region 10 Conference on Computer, Communication, Control and Power Engineering, vol. 1, Oct 1993, pp. 411414. [6] Q. Cui and J. D. Gannon, Data-oriented exception handling, IEEE Transactions on Software Engineering, vol. 18, no. 5, pp. 393401, 1992.

[7] Exceptions, http://docs.oracle.com/javase/specs/jls/se7/html/ jls-11.html, accessed: 05/06/2012. [8] Flight 501 failure, http://www.di.unito.it/damiani/ariane5rep .html, accessed: 04/09/2012. [9] The bug that destroyed a rocket, http://docenti.ing.unipi.it/ 009435/issw/extra/ariane5-benari.pdf, accessed: 04/09/2012. a [10] A. Romanovsky, On exceptions, exception handling, requirements and software lifecycle, in 2007 Proceedings of the 10th IEEE International Symposium on High Assurance Systems Engineering, Nov. 2007, pp. 301301. [11] J. B. Goodenough, Exception handling design issues, ACM SIGPLAN Notices, vol. 10, no. 7, pp. 4145, 1975. [12] R. A. Maxion and R. T. Olszewski, Eliminating exception handling errors with dependability cases: A comparative, empirical study, IEEE Transactions on Software Engineering, vol. 26, no. 9, pp. 888906, 2000. [13] C. A. R. Hoare, The emperors old clothes, Communication of the ACM, vol. 24, no. 2, pp. 7583, February 1981. [14] C. Marinescu, Are the classes that use exceptions defect prone? in 2011 Proceedings of the 12th International Workshop on Principles of Software Evolution and the 7th annual ERCIM Workshop on Software Evolution. ACM, 2011, pp. 5660. [15] H. B. Shah, C. Gorg, and M. J. Harrold, Understanding exception handling: Viewpoints of novices and experts, IEEE Transactions on Software Engineering, vol. 36, no. 2, pp. 150161, 2010. [16] R. J. Wirfs-Brock, Toward exception-handling best practices and patterns, IEEE Software, vol. 23, no. 5, pp. 1113, 2006. [17] A. Strohmeier and S. Chachkov, A side-by-side comparison of exception handling in Ada and Java, no. 3, pp. 4156, 2001. [18] About the eclipse foundation, http://www.eclipse.org/org/, accessed: 04/09/2012. [19] Bug reporting faq, http://wiki.eclipse.org/Bug Reporting FAQ, accessed: 04/01/2012. [20] T. Ozyer, K. Kianmehr, and M. Tan, Recent Trends in Information Reuse and Integration. Springer, 2011, pp. 173174. [21] TPTP development process, http://www.eclipse.org/ tptp/home/documents/process/development/bugzilla.html, accessed: 04/02/2012. [22] Checked or unchecked exceptions? http://tutorials.jenkov .com/java-exception-handling/checked-or-uncheckedexceptions.html, accessed: 04/09/2012.

97