AP is proud to sponsor “The complete guide to Solving Java Application Errors in Production” written by Alex Zhitnitsky at our friends OverOps. This blog is the second of a 3-part series looking at each of the chapters. The first blog in the series is here.   The second chapter’s title is “Source Code Crunch: Lessons from Analyzing over 600,000 Java projects”. It explores how exceptions are handled in a large number of GitHub and SourceForge projects. Perhaps it shouldn’t come as a surprise to find that they are not handled that well. In many cases, the compiler requirement to have checked exceptions explicitly declared or caught, leads to convoluted catch-block handling, with, at best, the exception logged and, at worst, empty catch blocks. As the book says, the motivation for building OverOps was “a Java agent that monitors JVMs in production and takes care of filling in the blanks with everything you need to know about how exceptions behave (and how to solve them)”. As we saw in the first article, OverOps is not a fan of non-actionable checked exceptions and thinks there should not be any. Java is the only major language with checked exceptions. Other languages, such as C#, do not have checked exceptions. In fact, many people think it was a mistake to introduce checked exceptions into Java. What do you think?