In my previous post, I explained the different types of exceptions in Java and left two questions for this post!
Which exception to use?
Java documentation and Uncle Bob’s book (Clean Code) were my references when preparing this tutorial. I noticed a slight difference between what is recommended in each!
Java Documentation
While reading the Java documentation, you sense a preference for Checked Exceptions. The documentation states that the usage of UnChecked Exceptions should be restricted to the case where crashing the system is intentional if an exception occurs. In other cases where recovery is still possible, Checked Exceptions should be used.
Robert Martin’s opinion
Uncle Bob has a different opinion! He argues that although Checked Exceptions might have some benefits and can be useful in some special cases like writing critical libraries, they are not a necessity to have a robust software.
Breaking the ‘Open/Closed Principle‘ and ‘Encapsulation‘ are the main two reasons that make using Checked Exceptions a bad idea!
Let’s see how!
In the below example, the MainBookReader.main method is calling the method MainBookReader.readJsonObject to get the book’s description from a JSON file. And since readJsonObject throws an exception we had to add throws FileNotFoundException clause to the signature of the main method and the interface JsonLoader!
import java.io.FileNotFoundException;
public class MainBookReader {
public static void main(String[] args) throws FileNotFoundException {
BookJsonLoader jsonLoader = new BookJsonLoader();
Book bookFromJson = jsonLoader.readJsonObject("books.json");
System.out.println(bookFromJson.name());
}
}
import com.google.gson.Gson;
import java.io.FileNotFoundException;
import java.io.FileReader;
public class BookJsonLoader implements JsonLoader {
public Book readJsonObject(String fileName) throws FileNotFoundException {
FileReader jsonFile = new FileReader(fileName);
Gson gson = new Gson();
return transformToBook(gson.fromJson(jsonFile, JsonBook.class));
}
private Book transformToBook(JsonBook jsonBook) {
return new Book(jsonBook.getName());
}
}
import java.io.FileNotFoundException;
public interface JsonLoader {
Book readJsonObject(String fileName) throws FileNotFoundException;
}
Adding the throws clause to most of our methods means two things!
- Our top methods & classes had to know a lot about the lower methods & classes!
- If any change is to be applied to the lower methods, this change has to be replicated to all above methods!
This is a violation of the ‘Open/Closed Principle‘ and ‘Encapsulation‘!
Is there a better way?
No matter how careful we are, things can still go wrong. Thus we still need to deal the exceptions when they occur! The alternative to the code above is writing clean code!
In this section, I will refactor the above code to make the code look better, although it might involve more code!
Wrap the Exception
The first step is to wrap the exception in one place! In our case, we can replace the throws clause with a try-catch!
In the catch clause, I’m throwing a JsonFileNotFoundException (UncheckedException) that I have created based on the needs of this system (i.e. providing an informative message to the user).
public class BookJsonLoader implements JsonLoader {
public Book readJsonObject(String fileName){
try {
FileReader jsonFile = new FileReader(fileName);
Gson gson = new Gson();
return transformToBook(gson.fromJson(jsonFile, JsonBook.class));
} catch (FileNotFoundException e) {
throw new JsonFileNotFoundException("Can't find the file " + fileName + ". Please make sure it exists!", e);
}
}
private Book transformToBook(JsonBook jsonBook) {
return new Book(jsonBook.getName());
}
}
The benefits of this refactoring are:
- Remove all ‘throws clauses.’
- Hide the logic and information of our class from the outer classes
- Send an informative message to the user in case the file was not found
- Minimize the dependency (remove imports from other classes)
Don’t return null
In some cases, developers don’t want to throw an UnCheckedException, so they tend to return a ‘null’ instead! That is a bad practice because it will eventually result in a NullPointerException later.
So, what to do? The answer is simple, return a SPECIAL CASE!
The below class ‘MissingBook‘ is our special case!
public class MissingBook extends Book {
private MissingBook(String name) {
super(name);
}
public static MissingBook aMissingBook() {
return new MissingBook("MISSING BOOK");
}
}
This allows us to return an instance of the MissingBook in the catch instead of throwing an exception!
public class BookJsonLoader implements JsonLoader {
public Book readJsonObject(String fileName){
try {
FileReader jsonFile = new FileReader(fileName);
Gson gson = new Gson();
return transformToBook(gson.fromJson(jsonFile, JsonBook.class));
} catch (FileNotFoundException e) {
return MissingBook.aMissingBook();
}
}
private Book transformToBook(JsonBook jsonBook) {
return new Book(jsonBook.getName());
}
}
Don’t pass null
In your code, you shouldn’t pass null as parameters and instead use the Special Cases as before. But, it gets harder to prevent your clients from passing nulls thus you might need to assert some function parameters before proceeding with your code execution!
Finally
Doing the refactoring for the simple example above might look like over-engineering! But, it becomes beneficial when writing more complex code!
I think that the excessive usage of CheckedExceptions will pollute the code and thus should be avoided! For me, the benefits of CheckedExceptions can still be achieved through:
- Following the rules of Clean Code
- Increase test coverage of the code by following the TDD practice! With the use of TDD, all the edge cases should be covered and thus eliminating the possibility of having unexpected exceptions during execution!
To understand better the importance and how to write clean code, it is highly recommended that you read the book Clean Code by Robert Martin!
