Where do RuntimeExceptions come from?

Andras Horvath
samebug
Published in
3 min readAug 23, 2018

In a recent blogpost we compared some of the main Java exceptions based on the number of crashes, common error-patterns and web-pages (from where we collected the crashes). We focused on NullPointerException and ClassNotFoundException. The post sparked some debate on Reddit which reflected the well-known and everlasting discussion about checked and unchecked exceptions in Java and how programmers should use RuntimeException in their code.

These were the main views:

  • this is the normal way to work around checked exceptions,
  • developers should use more specific/expressive unchecked exception types,
  • it’s ok to do this in your application, but not in a library.

We’ve decided to take another look at our data with the purpose of analyzing it from another angle to see where RuntimeExceptions come from. We’ve examined those stack traces which crashed with RuntimeExceptions and identified the component that crashed using our component resolver algorithm (the one we are using on Samebug to categorize error patterns). Of course, we cannot identify every single component but we are pretty sure that the majority of such crashes come from application code. Here are the results:

1. Proportion of components in RuntimeException / all crashes

The crashes without known component has the largest proportion in all crashes but in the case of RuntimeException, it’s proportion is even higher (52%). In the rightmost column the values greater than 1 mean that the given component is overrepresented compared to others in RuntimeExceptions.

Let’s also take a look at what’s the proportion of RuntimeException in a given component’s crashes. We’ve sorted the components in descending order according to this proportion.

2. Proportion of RuntimeException in components

There are some components with quite a lot of RuntimeExceptions among the crashes (hadoop-common is the winner in our database). The most notable of such components is Android which is ranked quite high on the list. We can note that the crashes supposedly related to application code (without known component in the table) have a prominent place in the list. Both comparisons suggest that RuntimeExceptions are far more frequent in application code than in library code.

Finally, we have examined which pages are the main sources of the crashes. RuntimeException crashes are most frequently debated on StackOverflow, the same is true for NoClassDefFound, ClassNotFoundException and IOException. Other main exceptions like NullPointerException, FileNotFoundException or NoSuchMethodError have GitHub issue in the first place.

If we compare RuntimeException with the average of the other main exception types, measured by the importance of sources, we can see that RuntimeExceptions appear on StackOverflow relatively more frequently than in GitHub issues. This is because GitHub issues (in contrast with StackOverflow questions) are more strongly related to library code than to application code.

3. Web sources

Thanks to Istvan Erdo and Daniel Poroszkai.

--

--