Boa Source Code

All Boa source used in our study are available publicly. To download the source code click on the following link: BoaCodes.zip

Additional Results

Top Ten Frequently Caught Exceptions in the Catch Statement
Exception Type	Count
Exception	3859217
IOException	2170519
SQLException	681638
Throwable	670214
InterruptedException	555555
IllegalArgumentException	460872
NumberFormatException	364362
NullPointerException	326193
RemoteException	263920
RecognitionException	203892

Top Ten Frequently Called methods in the Catch Block
Method Name	Count
printStackTrace	2394629
error	964525
println	900806
fail	514641
log	491596
warn	293645
warning	193069
recover	171744
reportError	167279
assertEquals	133770

We look for the answer of the following questions in this study:

(A) Exception Handling Coding Practices to Avoid

We consider the following improper/bad exception handling coding practices:

Improper Coding Practice	Description	Example
Ignoring exceptions (IE)	In this case developers leave the catch or finally block empty	catch(IOException e){ //empty catch block }
Catching unchecked exception (CUE)	Developers catch unchecked exceptions. However, Unchecked exceptions results of programming errors that can be fixed by checking proper conditions	catch(ArrayIndexOutOfBoundsException e){ // do something }
Not preserving original exception (NPOE)	Developers re-throw an exception without wrapping the original exception object within the new exception object.Thus they are throwing the exception by loosing the original source of the problem	catch (IOException e){ throw new Exception (“Error”);}
Use generic exception handler (UGEH)	Instead of catching specific exceptions developers use a single catch block to collect all exceptions	try{ //throw three different kinds of exceptions }catch (Exception e){ //a single catch block that collects all exceptions }
Catching Error (CE)	Developers should not catch exceptions indicated by Error or its subclasses.	catch(Error e){ // code goes here }

The above figure shows the frequency of improper exception handling coding practices in GitHub. We find that using generic exception handler is the most frequent one. This is an indication that developers are very reluctant in using exception handling. Then comes the ignoring exceptions. Many developers are not aware of recovering from exceptions and thus leave the catch and finally blocks empty. This could cause difficulties maintaining applications as well as leave potential bugs in the code. We found a very small number of code examples where developers catch the error, indicates that most developers are aware of this bad practice.
 

(B) How developers use exception chaining ?

To use exception chaining application uses throw statement that throws an exception in response to another exception. We are interested to investigate the patterns of throwing exceptions. The data can help other developers to learn various ways of constructing the throw statements.

Expression Type	Percent	Example
Cast	1.0215	catch(CustomException ex){ throw (UnsupportredEncodingException) ex;}
Conitional	0.0535	catch(Exception ex){ error_code==0? throw new RuntimeException(“Error message”,ex): throw new Exception(“Another message”,ex); }
Method Call	5.8479	catch(Expression ex){ throw InvocationTargetException.getCause();}
New	76.1696	catch(Expression ex){ throw new Exception(“Additional error message”,ex) }
Variable Access	16.8920	catch(Expression ex){ throw ex; }
Assignment	0.0147	catch(Expression ex) { throw lastException = new KeyStrokeException(ex); }
Null	0.0008	catch(Expression ex) { return null ; }

The above table shows various ways of writing throw statements in exception chaining. We see that the largest number of throw statements in exception chaining uses new expression type where they throw a new exception object that incorporates additional error message and may also contain reference to the lower level exceptions. Conditional expressions can be used to throw different expression objects with different error message information depending on some conditions. The assignment and null expressions are very infrequent. Expressions of variable access category become the second and the method call become the third most popular expression type used in exception chaining.

(C) How developers define their own exceptions?

Interestingly when we investigate this in GitHub data set we found that in majority of the cases developers define their own exception classes by extending Exception. This indicates that when developers create their own exceptions, they are concerned about error recovery. We also observe evidence where developers create exception classes by extending Runtime, Throwable or Error, but those cases are very few in numbers.

(D) When do developers use new exception handling features?

We found that not only developers use the new features in their code, but also developers start using these features long before their release.

(E) Do developers’ experience affect exception handling coding practices?

Results from our study shows that regardless of the experience all developers use exception handling coding bad practices. Expert developers are also not concerned using exception handling and in many cases they do not try to avoid the improper coding practices.