The execution of a program can suddenly terminate for several reasons. To prevent unexpected program behaviors, developers can include error handling mechanisms in their programs. Specifically, in Java, developers can use two types of exceptions: checked and unchecked. Checked exceptions (IOException, DataFormatException, ParseException, SQLExceptions, etc.) are always caught on compile time, whereas unchecked exceptions (OutOfMemoryError, ArithmeticException, NullPointerException, IllegalArgumentException, IllegalStateException, etc.) can occur on runtime and lead a program to an unexpected termination (crash)—if there is no prevention mechanism in the source code to caught the exception. However, there is a debate regarding the use of the unchecked exceptions in the source code (see Unchecked Exceptions — The Controversy, in the Java documentation).
When designing and implementing an Application Programming Interface (API), things about exceptions are getting even worse, since other developers can use the same source code to build their applications. First, API designers have to decide whether they will include in their API existing exceptions (e.g. from the Java API) or they will use new exceptions according to their needs. Second, they need to make clear the use of their exceptions, through the API reference, so that the developers of the client code can use these exceptions correctly. Finally, API designers should include in their API as many exceptions as it is necessary, without making the API too complex. Namely, they should include all the checked exceptions and some of the unchecked exceptions that the client application are able to recover from exceptional cases.
It is not easy to decide which unchecked exceptions to include in an API. API designers can intuitively decide according to their experience and needs, but this experience can differ from the level of experience of the developers of client applications. Then, it would be safe if API designers could include in their API references all the unchecked exceptions that could lead client applications to crashes. This is quite demanding, however, since API designers cannot always get feedback (e.g. from stack traces) on how their APIs are used in client code. For this reason, careful API designers should conduct rigorous testing on their source code, in order to find as many “dangerous” paths of method calls that lead to unchecked exceptions as it is possible.
In particular, from an empirical study we conducted on the Android API (level 15), we found that almost 18% of the methods of the Android API had documented exceptions . Also, given a number of stack traces from Android application crashes, we found that 19% of the crashes could have been avoided if specific exceptions were in the API reference. In the following table, we present the top 10 API methods that were involved in crashes and they had undocumented exceptions .
 Maria Kechagia and Diomidis Spinellis. 2014. Undocumented and unchecked: exceptions that spell trouble. In Proceedings of the 11th Working Conference on Mining Software Repositories (MSR 2014). ACM, New York, NY, USA, 312-315. DOI=10.1145/2597073.2597089 http://doi.acm.org/10.1145/2597073.2597089