What are checked and unchecked exceptions in Java?

Some exceptions in Java must be handled in developer code. Other exceptions may occur without any exception handling semantics. When an exception must be handled with try-and-catch semantics, it is called checked exceptions. If the try-and-catch semantics are not required, this is an unchecked exception.

Example of checked exception

A checked exception in Java represents a predictable, erroneous situation that can occur even if a software library is used as intended.

For example, if a developer tries to access a file, the Java IO library forces him to process the checked box FileNotFoundException. The Java IO API developers anticipated that attempting to access a file that does not exist would be a relatively common event, so they created a checked exception to force a developer to deal with it.

Example of an unchecked exception

Unlike a checked exception, an unchecked exception represents an error in programming logic, not an erroneous situation that could reasonably occur when using an API correctly.

Because the compiler cannot anticipate logical errors that only occur at runtime, it cannot look for these types of problems at compile time. This is why they are called “unchecked” exceptions.

Unchecked exceptions result from faulty logic that can occur anywhere in a software program. For example, if a developer invokes a method on a null object, an unchecked object NullPointerException occurs. If a developer attempts to access an array element that does not exist, the unchecked box ArrayIndexOutOfBoundsExceptionArrayIndexOutOfBoundsException occurs.

Compare checked and unchecked exceptions

Criteria Unchecked exception Exception checked
Goal Unexpected errors in logic that appear at runtime Anticipated issues with normal API usage
Ancestry Include runtime exception Does not include RuntimeException
Handling Exception handling semantics are not required Must be handled in a try-and-catch block, or be started by the invoke method
Extension Can be customized by extending RuntimeException Can be customized by extending java.lang.Exception
List of examples NullPointerException, ClassCastException, ArithmeticException, DateTimeException, ArrayStoreException ClassNotFoundException, SocketException, SQLException, IOException, FileNotFoundException

Handling checked and unchecked exceptions

The following example compares checked and unchecked exceptions.

public static void main(String[] args) {
 /* checked vs unchecked exception example */
 try {
 } catch (ClassNotFoundException e) {
  System.out.println("Class was not found.");
 String input = null;
 input.length(); // throws an unchecked exception

First the Class.forName() the method loads the named class com.mcnz.CheckedClass in the JVM. The API developer knows that it is possible that the class does not exist, so he is forced to handle the ClassNotFoundExceptionClassNotFoundException through try-and-catch semantics.

As the code executes, the forName() method may never actually throw a ClassNotFoundExceptionClassNotFoundException. Nevertheless, the developer is obligated to handle this checked condition.

Let us now examine the assignment of the Rope appointed grab for noand more length(). This input.length() the invocation triggers a NullPointerException and causes the program to fail each time it runs. This is an unchecked exception caused by poor programming practices that are not revealed until the program is run. Therefore, it does not require any exception handling semantics.

Modern use of unchecked exceptions

The technical description of checked and unchecked exceptions provided in this article is consistent with how the creators of the Java language envisioned their use. However, the syntactic ceremony associated with handling checked exceptions, especially when there is little chance of recovering from them, tends to make Java code more verbose, less readable, and more difficult to maintain.

The general trend in the industry is to move away from extensive creation of checked exceptions in an API or framework.

Many frameworks, including Spring, simply catch checked exceptions and then throw them back as unchecked exceptions. A global exception bundle then catches all unchecked exceptions and runs generic exception handling and recovery routines.

Comments are closed.