7.2. Categories of exceptions

[8.1] Differentiate among checked exceptions, unchecked exceptions, and Errors

The Java compiler and its runtime treat the exception categories in a different manner. This implies that separate rules exist to define methods that throw exceptions and code that handles them.

In this section, you’ll learn about the categories of exceptions in Java: checked exceptions, runtime exceptions, and errors.

7.2.1. Identifying exception categories

As depicted in figure 7.8, exceptions can be divided into three main categories:

• Checked exceptions
• Runtime exceptions
• Errors

Figure 7.8. Categories of exceptions: checked exceptions, runtime exceptions, and errors

Note

Runtime exceptions and errors are collectively referred to as unchecked exceptions.

Of these three types, checked exceptions require most of your attention when it comes to coding and using methods. Runtime exceptions represent programming errors. Checks should be inserted to prevent runtime exceptions from being thrown. There are few options you can use for the errors, because they’re thrown by the JVM.

For the OCA Java SE 8 Programmer I exam, it’s important to have a crystal-clear understanding of these three categories of exceptions, including their similarities and differences.

7.2.2. Class hierarchy of exception classes

Exception categories are related to each other; all extend the class java.lang.Throwable (as shown in the class hierarchy in figure 7.9).

Figure 7.9. Class hierarchies of exception categories

Here’s the categorization of exceptions based on their class hierarchy:

• Checked exceptions—java.lang.Exception and its subclasses (excluding java.lang.RuntimeException and its subclasses)
• Runtime exceptions—java.lang.RuntimeException and its subclasses
• Errors—java.lang.Error and its subclasses

Let’s examine each of these categories in detail.

7.2.3. Checked exceptions

When we talk about handling exceptions, checked exceptions take up most of our attention.

What is a checked exception?

• A checked exception is an unacceptable condition foreseen by the author of a method but outside their immediate control. For an example, FileNotFoundException is a checked exception. This exception is thrown if the file that the code is trying to access can’t be found. A method, say, readFile(), can declare it to be thrown when it’s unable to access the target file.
• Checked exceptions are so named because they’re checked during compilation. If a method call throws a checked exception, the compiler checks and ensures that the calling method is either handling the exception or declaring it to be rethrown.
• checked exception is a subclass of the class java.lang.Exception, but it’s not a subclass of java.lang.RuntimeException. It’s interesting to note, however, that the class java.lang.RuntimeException itself is a subclass of the class java.lang.Exception.

Exam Tip

In this exam, you may have to select which type of reference variable to use to store the object of the thrown checked exception in a handler. To answer such questions correctly, remember that a checked exception subclasses java.lang.Exception but not java.lang.RuntimeException.

A checked exception is part of the API and is well documented. For a quick example, here’s the declaration of the constructor of the class java.io.FileInputStream in the Java API:

public FileInputStream(File file)
                throws FileNotFoundException

Checked exceptions are unacceptable conditions that a programmer foresees at the time of writing a method. By declaring these exceptions as checked exceptions, the author of the method makes its users aware of the exceptional conditions that can arise from its use. The user of a method with a checked exception must handle the exceptional condition accordingly.

7.2.4. Runtime exceptions

Although you’ll spend most of your time and energy combating checked exceptions, the runtime exceptions will give you the most headaches. This is particularly true when you’re preparing to work on real-life projects. Some examples of runtime exceptions are NullPointerException (the most common one), ArrayIndexOutOfBounds-Exception, and ClassCastException.

What is a runtime exception?

• A runtime exception is a representation of a programming error. These occur from inappropriate use of a piece of code. For example, NullPointerException is a runtime exception that occurs when a piece of code tries to execute some code on a variable that hasn’t been assigned an object and points to null. Another example is ArrayIndexOutOfBoundsException, which is thrown when a piece of code tries to access an array element at a nonexistent position.
• A runtime exception is named so because it isn’t feasible to determine whether a method call will throw a runtime exception until it executes.
• A runtime exception is a subclass of java.lang.RuntimeException.
• It’s optional to declare a runtime exception in the signature of a method. It’s up to the person who writes the code to decide whether to declare it explicitly or not.

Exam Tip

Together, runtime exceptions and errors are referred to as unchecked exceptions.

7.2.5. Errors

Whether you’re preparing for this exam or your real-life projects, you need to know when the JVM throws errors. These errors are considered to be serious exceptional conditions and they can’t be directly controlled by your code.

What is an error?

• An error is a serious exception thrown by the JVM as a result of an error in the environment state that processes your code. For example, NoClassDefFound-Error is an error thrown by the JVM when it’s unable to locate the .class file that it’s supposed to run. StackOverflowError is another error thrown by the JVM when the size of the memory required by the stack of a Java program is greater than what the JRE has offered for the Java application. This error might also occur as a result of infinite or highly nested loops.
• An error is a subclass of class java.lang.Error.
• An error need not be a part of a method signature.
• An error can be caught by an exception handler, but it shouldn’t be.

Let’s move on to creating methods that throw exceptions.