How Developers Use Exception Handling in Java?

Exception handling is a technique that addresses exceptional conditions of applications, allow them to continue the normal flow of of executions in the event of exceptions or report such events to developers. Although techniques, features and bad coding practices of exception handling have been discussed both in developer communities and in the literature, there is a marked lack of empirical evidence of how developers use exception handling in practice.  We use Boa language and infrastructure to analyze 274k open source Java projects in GitHub to discover how developers use exception handling. We not only consider various exception handling features but also explore bad coding practices and their relationship to the experience of developers. Our result gives some interesting insights. For example, we found that bad exception handling coding practices are common in source code projects and regardless of the experience all developers use exception handling coding bad practices.

Boa Source Code

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

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.