Reading the chapter ‘Error Handling‘ from the book ‘Clean Code‘ made me think whether developers follow the clean code rules when writing production code. It also appeared to me that the difference between the Java exception types might not clear be for some!

The purpose of this short tutorial is to clarify those two points. And to make it clearer, I will be dividing it into two posts. In the first one, I will explain the different types of Java exceptions. Whereas in the second one, I will show how to write clean exception code!

Java Exceptions

In Java, the class Throwable is at the top of the class hierarchy of all exceptions. The classes Error and Exception directly extend Throwable. All the subclasses of Error and Exception are grouped into two types ‘Checked Exceptions‘ and ‘UnChecked Exceptions‘as displayed in the image below.

What is the difference between Checked and UnChecked Exceptions?

UnChecked Exceptions

UnChecked Exceptions extend the classes ‘Error‘ or ‘RuntimeException‘. In this case, developers don’t have to worry about catching or handling the exceptions at compile time as the compiler won’t report any error. But, as they are not caught, those exceptions may result in complete failure of the application when thrown during execution.

Below are two examples of UnChecked Exceptions!

1. Runtime Exception

The below method simply divides two numbers:

private static int divide(int numerator, int denominator) {
    return numerator / denominator;
}

The code is fine and will compile with no errors! So what is the problem?

The problem might occur at runtime if we try to call the method while passing zero as the denominator. Since this exception is not caught, our system will crash throwing the below arithmetic exception:

Exception in thread "main" java.lang.ArithmeticException: / by zero
 at MainUnCheckedException.divide(MainUnCheckedException.java:7) ...

2. Error

The below method compiles, but since I missed writing the base cases calling the method will crash the system and throw a StackOverflowError (as shown below) will throw an Error!

private static int fibonacci(int number) {
    return fibonacci(number - 1) + fibonacci(number - 2);
}

Exception in thread "main" java.lang.StackOverflowError
 at MainUnCheckedException.fibonacci(MainUnCheckedException.java:10)...

Checked Exceptions

On the other hand, all other classes extending the ‘Exception‘ class are considered to be Checked Exceptions. In this case, the code will not compile if the developer doesn’t explicitly handle the exception.

This adds a level of security to your code, as you are forced to specify how your code should behave when an exception occurs and thus decreases the chance of having an unrecoverable failure in the system.

Let’s see an example!

public class MainCheckedException {
    public static void main(String[] args) {
        FileInputStream fileInputStream = new FileInputStream("foo.txt");
    }
}

Error:(6, 43) java: unreported exception java.io.FileNotFoundException;
must be caught or declared to be thrown

In the above code, we are trying to read a file ‘foo.txt’, but our compiler complains that we need to handle the FileNotFoundException.

Solving this compilation error can be done in two ways:

1. Try Catch: The first solution requires surrounding the code with a try-catch.

   private static void readFileTryCatch() {
       try {
           FileInputStream fooFile = new FileInputStream("foo.txt");
       } catch (FileNotFoundException e) {
           System.out.println(e.getMessage());
       }
   }

   Even if the file was not there, this code would not break thanks to the try-catch. As shown in the below code and output, the system will print out the exception and continue execution!

   public static void main(String[] args) {
       readFileTryCatch();
       System.out.println("Done");
   }
   ------------Output------------
   foo.txt (No such file or directory)
   Done

2. Throw an exception: The other solution is adding a ‘throws FileNotFoundException‘ to the method signature.

   private static void readFileThrow() throws FileNotFoundException {
       new FileInputStream("foo.txt");
   }

   Using this solution will propagate handling the exception to the calling methods as illustrated in the two options below:
   Option 1: Adding throws to all methods signatures 

   public static void main(String[] args) throws FileNotFoundException {
       readFileThrow();
       System.out.println("Done");
   }

   ------------Output------------
   Exception in thread "main" java.io.FileNotFoundException: foo.txt (No such file or directory)
   at java.io.FileInputStream.open0(Native Method) ...

   Option 2: Catching the exception in one of the methods in the call stack

   public static void main(String[] args)  {
       try {
           readFileThrow();
       } catch (FileNotFoundException e) {
           System.out.println(e.getMessage());
       }
       System.out.println("Done");
   }

   ------------Output------------
   foo.txt (No such file or directory)
   Done

I hope this post gave you a better understanding of Java exceptions! In the 2nd part, I will be sharing more details on how to properly write exceptions in clean code and which of the two exception types to use!