Recently, I was working on this project and I had just finished up the refactoring of it. A colleague came over to review my code and he pointed out that there have always been a bunch of places that make remote calls and often fail in ways that are out of our control. He wanted me to make sure we handle all of those situations. The way this legacy code was written made that pretty difficult because these remote calls were made all over the place.
I realized that Java comes with a really good solution to this problem: Checked exceptions. If you’re not familiar with checked exceptions, they are a way to force the code that calls a method to deal with the possibility that an error might occur. Here’s an example:
|
1 2 3 4 5 6 7 |
Integer i = null; try { BufferedReader bufferedReader = new BufferedReader(new FileReader("/foo/bar.txt")); System.out.println(i.toString()); } catch (FileNotFoundException e) { e.printStackTrace(); } |
In this case, FileNotFoundException is a checked exception. Because it’s a checked exception, my code is forced to deal with it or it will not compile. On the other hand, the Integer i is null, but my code does not have to deal with that possibility when I call toString on it. This is called a run time exception because the error happens when I run my code (as opposed to when I compile it).
People always complain about checked exceptions and based off of the way new programming languages are being developed, it seems like most agree with the sentiment. I can’t think of a programming language since Java came out that has them.
But, like I said, I thought they could be useful sometimes. Like in this case, it is great that the compiler can tell me that I forgot to deal with the fact that a remote API can be down. I should be forced to deal with this because it is likely to happen and my code is capable of reacting to it.
That said, I always complained about all the IOException s I have to deal with when I’m writing code that deals with files, etc. After all, who is Java to assume that my code is the best place to deal with a missing file? It completely depends on the context: What if that file should be there and the system can’t recover from it being missing? The application definitely should fail at that point and require developer intervention. On the other hand, if the user is providing the path to a file, it’s perfectly reasonable to expect them to provide a path with a typo in it on occasion. In that situation, a checked exception is very convenient. That’s why I now say, “One man’s checked exception is another man’s run time exception”.
Oh, and how does this relate to my story about the unstable remote APIs? Well, I thought the remote APIs were a perfect fit for checked exceptions. Then I realized how convenient it would be to reuse the same remote APIs in a quick, script-like application that fills the remote system up with test data. In this context, the checked exceptions got in my way more than they helped me. In this situation, a runtime exception made sense in one project but not another. I guess that’s why new programming languages decided to avoid them.