Java is one of the only, if not the only, mainstream programming language which differentiates between Checked Exceptions and Runtime Exceptions.

Checked Exceptions are supposed to be used for conditions from which the caller is expected to be able to reasonability recover. Runtime (or Unchecked) Exceptions indicate unrecoverable programming errors such as a NullPointerException or an IndexOutOfBoundsException exception. The Java compiler forces developers to explicitly handle any Checked Exception that may thrown in their code or any API or library that their code depends on.

Checked Exceptions were intended to encourage software reliability & resilience. Unfortunately for many programmers the cost of Checked Exceptions significantly outweighs their utility.

In practice, in a lot of codebases (including well-known production projects), most try/catch blocks are effectively a no-op. They simply rethrow or print the error, or worse yet encourage horrible anti-patterns (such as writing empty try/catch blocks, or declaring that all methods throw Exception to account for all possible erroneous conditions.

Recently, several well-regarded experts, including Bruce Eckel and Rod Johnson, have publicly stated that while they initially agreed completely with the orthodox position on checked exceptions, they've concluded that exclusive use of checked exceptions is not as good an idea as it appeared at first, and that checked exceptions have become a significant source of problems for many large projects. Eckel takes a more extreme view, suggesting that all exceptions should be unchecked; Johnson's view is more conservative, but still suggests that the orthodox preference for checked exceptions is excessive. (It's worth noting that the architects of C#, who almost certainly had plenty of experience using Java technology, chose to omit checked exceptions from the language design, making all exceptions unchecked exceptions. They did, however, leave room for an implementation of checked exceptions at a later time.)

Java theory and practice: The exceptions debate

Unchecked Java is designed to circumvent Java's exception handling mechanisms and allow developers to treat Checked Exceptions as unchecked.

• Provided checked variants of all unchecked functional interfaces in the java.util.function package in Java 8 (e.g. BiFunction -> CheckedBiFunction)
• Provide checked variants of Runnable and Comparator
• Include all higher-order functions (e.g. Comparator.thenComparing(Comparator) -> CheckedComparator.thenComparing(CheckedComparator))
• Provide adapter methods to view all checked variants as unchecked (e.g. CheckedComparator.unchecked(CheckedComparator))
• Expose functionality to rethrow Checked Exceptions as unchecked

• Provide additional uncheckedGet methods for all Supplier interfaces